Bug 1025906 - Locale::Maketext interpolating escaped backslashes improperly
Locale::Maketext interpolating escaped backslashes improperly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: perl (Show other bugs)
6.6
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Petr Pisar
Martin Kyral
: Patch, Regression
Depends On:
Blocks: 1070830 1159820
  Show dependency treegraph
 
Reported: 2013-11-01 18:25 EDT by Dan Eggleston
Modified: 2015-07-22 01:59 EDT (History)
6 users (show)

See Also:
Fixed In Version: perl-5.10.1-138.el6
Doc Type: Bug Fix
Doc Text:
The Perl Locale::Maketext localization framework did not properly translate the backslash (\) characters. As a consequence, Perl rendered the backslashes as double (\\). With this update, Perl no longer escapes the backslashes in literal output strings, and they appear correctly.
Story Points: ---
Clone Of:
: 1026761 1026763 1029016 (view as bug list)
Environment:
Last Closed: 2015-07-22 01:59:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Reproducer (916 bytes, text/plain)
2013-11-04 08:04 EST, Petr Pisar
no flags Details
Upstream partial fix for non-parametrized case (1.38 KB, patch)
2013-11-04 09:34 EST, Petr Pisar
no flags Details | Diff
Proposed fix for parametrized case (3.29 KB, patch)
2013-11-05 06:24 EST, Petr Pisar
no flags Details | Diff
Upstream fix (3.53 KB, patch)
2013-11-11 04:41 EST, Petr Pisar
no flags Details | Diff
Upstream tests (870 bytes, text/plain)
2013-11-11 08:23 EST, Petr Pisar
no flags Details
Upstream fix ported to 5.8.8 (3.56 KB, patch)
2014-02-11 09:53 EST, Petr Pisar
no flags Details | Diff
Upstream fix ported to 5.10.1 (3.63 KB, patch)
2015-01-07 03:13 EST, Petr Pisar
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
CPAN 120457 None None None Never

  None (edit)
Description Dan Eggleston 2013-11-01 18:25:28 EDT
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'.
Comment 2 Petr Pisar 2013-11-04 07:16:19 EST
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.
Comment 3 Petr Pisar 2013-11-04 08:04:39 EST
Created attachment 819144 [details]
Reproducer
Comment 4 Petr Pisar 2013-11-04 09:34:59 EST
Created attachment 819195 [details]
Upstream partial fix for non-parametrized case
Comment 6 Petr Pisar 2013-11-05 06:24:06 EST
Created attachment 819662 [details]
Proposed fix for parametrized case
Comment 7 Petr Pisar 2013-11-11 04:41:00 EST
Created attachment 822328 [details]
Upstream fix

Fix accepted by upstream in slightly different form. Only this one is needed to fix the regression.
Comment 8 Petr Pisar 2013-11-11 08:23:50 EST
Created attachment 822402 [details]
Upstream tests

Use this script for tests.
Comment 9 Petr Pisar 2014-02-11 09:53:42 EST
Created attachment 861802 [details]
Upstream fix ported to 5.8.8

This adds additional required fix for literal strings.
Comment 11 Joe Orton 2014-08-27 07:08:00 EDT
Dan, if this is an issue for you on productions systems, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization to assure a timely resolution.

http://www.redhat.com/en/services/support
Comment 13 Dan Eggleston 2014-08-27 07:24:47 EDT
Thanks, Joe. I was able to work around this by wrapping the character escapes within sprintf function calls, so production systems are no longer affected.
Comment 15 Petr Pisar 2015-01-07 03:13:00 EST
Created attachment 977122 [details]
Upstream fix ported to 5.10.1
Comment 16 Petr Pisar 2015-01-07 03:58:28 EST
How to test:

(1) Run the reproducer from attachment #8 [details].
(2) Check the output:
Before: Some back-slashes are doubled.
After: There are only single back-slashes.
Comment 21 errata-xmlrpc 2015-07-22 01:59:27 EDT
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.

https://rhn.redhat.com/errata/RHBA-2015-1266.html

Note You need to log in before you can comment on or make changes to this bug.