Bug 431041 - "perldoc perlvar" renders incorrectly in C and en_US.UTF-8 locales.
"perldoc perlvar" renders incorrectly in C and en_US.UTF-8 locales.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: perl (Show other bugs)
5.1
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Stepan Kasal
desktop-bugs@redhat.com
:
Depends On:
Blocks: 957079
  Show dependency treegraph
 
Reported: 2008-01-31 07:24 EST by Alex Page
Modified: 2013-04-26 06:15 EDT (History)
2 users (show)

See Also:
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 16:11:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alex Page 2008-01-31 07:24:01 EST
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 08:49:57 EDT
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 10:05:25 EDT
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 Product and Program Management 2008-06-02 16:20:27 EDT
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 16:11:18 EST
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.