Bug 431041 - "perldoc perlvar" renders incorrectly in C and en_US.UTF-8 locales.
Summary: "perldoc perlvar" renders incorrectly in C and en_US.UTF-8 locales.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: perl
Version: 5.1
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Stepan Kasal
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 957079
TreeView+ depends on / blocked
 
Reported: 2008-01-31 12:24 UTC by Alex Page
Modified: 2013-04-26 10:15 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 554654 957079 (view as bug list)
Environment:
Last Closed: 2009-01-20 21:11:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0117 0 normal SHIPPED_LIVE perl bug fix update 2009-01-20 16:04:48 UTC

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


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