Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 431041

Summary: "perldoc perlvar" renders incorrectly in C and en_US.UTF-8 locales.
Product: Red Hat Enterprise Linux 5 Reporter: Alex Page <alexp>
Component: perlAssignee: Stepan Kasal <kasal>
Status: CLOSED ERRATA QA Contact: desktop-bugs <desktop-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 5.1CC: mmaslano, psplicha
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 554654 957079 (view as bug list) Environment:
Last Closed: 2009-01-20 21:11:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 957079    

Description Alex Page 2008-01-31 12:24:01 UTC
Description of problem:

The rendering of the ASCII document /usr/lib/perl5/5.8.8/pod/perlvar.pod by 
the "perldoc" program produces incorrect output in different locales.

Version-Release number of selected component (if applicable):

$ rpm -q perl
perl-5.8.8-10

How reproducible:

Always

Steps to Reproduce:
1. echo $LANG
2. LANG=C perldoc perlvar | egrep -A 1 '  \$(PRE|POST)MATCH'
3. LANG=en_US.UTF-8 perldoc perlvar | egrep -A 1 '  \$(PRE|POST)MATCH'
4. LANG=C egrep -A 2 '=item \$(PRE|
POST)MATCH' /usr/lib/perl5/5.8.8/pod/perlvar.pod
5. LANG=en_US.UTF-8 egrep -A 2 '=item \$(PRE|
POST)MATCH' /usr/lib/perl5/5.8.8/pod/perlvar.pod

  
Actual results:

1.

en_US.UTF-8

2. 

       $PREMATCH
       $'      The string preceding whatever was matched by the last success-
--
       $POSTMATCH
       $'      The string following whatever was matched by the last success-

3.

       $PREMATCH
       $‘      The string preceding whatever was matched by the last success-
--
       $POSTMATCH
       $’      The string following whatever was matched by the last success-

4. & 5.

=item $PREMATCH

=item $`
--
=item $POSTMATCH

=item $'

Expected results:

1.

en_US.utf-8

2. & 3.


       $PREMATCH
       $`      The string preceding whatever was matched by the last success-
--
       $POSTMATCH
       $'      The string following whatever was matched by the last success-

4. & 5.

=item $PREMATCH

=item $`
--
=item $POSTMATCH

=item $'

Additional info:

Comment 1 Stepan Kasal 2008-05-08 12:49:57 UTC
The report does not exactly say what's the problem.  Looking at the
Actual&Expected output, I noticed only one the various apostrophes after the
dollar signes are garbled (as if they were part of text quoting).

Let me investigate.

Comment 2 Stepan Kasal 2008-05-08 14:05:25 UTC
Bug confirmed.  The problem is that perldoc is based on nroff, and in nroff,
these two ASCII characters (GRAVE accent and APOSTROPHE) do not map to themselves.

In nroff, you can use \` and \(aq, respectively, to get the characters.  But
AFAIK, this is not mapped to perldoc.

A possible fix is to use C<$`> and C<$'>, perldoc will then map the chars to
these control sequences.  (Unfortunately, it will also enclose the string into a
pair of quotes (for nroff on tty, troff output is ok), but that's still smaller
evil then the original garbage.)

Comment 3 RHEL Program Management 2008-06-02 20:20:27 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 11 errata-xmlrpc 2009-01-20 21:11:18 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0117.html