+++ This bug was initially created as a clone of Bug #1025906 +++ Description of problem: When a literal backslash is in an L10N value, it is treated nonuniformly by the Locale::Maketext::_compile method, as patched by RH in Locale::Maketext::Guts (per https://bugzilla.redhat.com/show_bug.cgi?id=884354). The result depends on unrelated parts of the string. Version-Release number of selected component (if applicable): perl-5.10.1-131.el6_4.x86_64 How reproducible: Always Steps to Reproduce: 1. Create a language token, whose value is 'Some data\n' 2. Query the language token through Locale::Maketext ($lh->maketext($tag)) Actual results: 'Some data\\n' Expected results: 'Some data\n' Additional info: The behavior changes in the following cases: 1) If the value contains a tokenized field, behavior depends on whether there is a trailing newline: '[_1]Some data\n' => 'Some data\n' '[_1]Some data\n'."\n" => 'Some data\\n ' 2) If the escaped backslash is in a function call, it behaves as expected: 'Some data[sprintf,\n]' => 'Some data\n' NOTE: All of these cases in standard perl (with Locale::Maketext v 1.13 from CPAN) behave exactly the same as each other, and they all produce just a single '\' before the 'n'. --- Additional comment from RHEL Product and Program Management on 2013-11-01 22:52:05 GMT --- Since this bug report was entered in bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. --- Additional comment from Petr Pisar on 2013-11-04 12:16:19 GMT --- The 'Some data\n' is due to back-porting the fix to perl 5.10.1. The parameterized case behaves for me differently and is caused by the changes in the fix. Even latest Locale::Maketext is affected. --- Additional comment from Petr Pisar on 2013-11-11 09:41:00 GMT --- Fix accepted by upstream in slightly different form. Only this one is needed to fix the regression. ---- perl-5.8.8-42.el5 is affected.
Created attachment 861777 [details] Upstream fix ported to 5.8.8
Created attachment 861801 [details] Upstream fix ported to 5.8.8 This solves tests failure at "Unicode literal" test. This bug remained hidden in current upstream code because there is a special short path for literal strings.
How to test: Use script from bug #1025906 comment 8. This is a upstream test I ported into perl 5.8.8.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1198.html