Bug 74706 - 'man' pages look funny in most locales by default.
'man' pages look funny in most locales by default.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: util-linux (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-30 21:38 EDT by Ali-Reza Anghaie
Modified: 2007-04-18 12:46 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-29 10:58:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ali-Reza Anghaie 2002-09-30 21:38:33 EDT
Description of Problem: 
 
'man' pages have odd characters instead of dashes and bold type in the locales 
I've tried. en_US.UTF-8 and en_GB.utf8 but I remember doing one more, can't 
remember what it was though. 
 
Furthermore, the behavior changes under 'screen' sometimes. So it might work 
normally and not in screen or visa-versa. 
 
export LANG=C  (or POSIX) 
 
fixes the viewing problems. 
 
This is just growing pains with UNICODE I guess. Not horrible but it is rather 
annoying trying to read manpages. 
 
My current i18n settings: 
 
LANG="POSIX" 
SUPPORTED="en_US.UTF-8:en_US:en" 
SYSFONT="latarcyrheb-sun16" 
 
The original settings that didn't display proper: 
 
LANG="en_US.UTF-8" 
SUPPORTED="en_US.UTF-8:en_US:en" 
SYSFONT="latarcyrheb-sun16" 
 
Two more notes. Linking more to less seems to fix the problem too. And an 
upgrade of screen seems to fix the behavior being different when in screen. 
 
Version-Release number of selected component (if applicable): 
 
glibc-2.2.93-5 
man-1.5j-11 
util-linux-2.11r-10 
less-358-28 
 
How Reproducible: 
 
Always for my default US installs. 
 
Steps to Reproduce: 
1. Install RH 8.0 with en_US or en_GB.  
2. "man ls" 
3. Frown at odd looking characters in your konsole, xterm, whatever. 
 
Actual Results: 
 
'man' pages show odd characters instead of dashes and bolding. Among other 
things I'm sure. 
 
Expected Results: 
 
Nice visually clean man pages (no praying for content ;-)). 
 
Additional Information: 
 
Please re-consider the default COLLATE behavior as well. You might also want 
to see bug 74701 which records some odd behavior in locale for X processes vs. 
text terminal. Anyhow. 
 
Cheers, -Ali
Comment 1 Ali-Reza Anghaie 2002-09-30 21:49:05 EDT
As the brilliant Red Hat employee know as 'Spot' told me, "export PAGER=less" 
is a better idea but I like less anyhow. So I'll keep linking it too.  ;-) 
 
Just in case anybody else besides a RH employee reads this. -Ali
Comment 2 Jesse Keating 2002-10-01 02:04:39 EDT
I was able to duplicate this bug.  Even though I have set /etc/sysconfig/i18n to
LANG=en_US, I was able to duplicate the garbled man pages by running:

[jkeating@yoda jkeating]$ LANG=en_US.UTF-8 man bash

An excerpt of the man page follows:

            INVOCATION below).
       br        If  the  br  option  is present, the shell becomes restricted


NOTE:  it only appears garbled once the pager is envoked.  The first viewable
portion of the man page looks fine.
Comment 3 Ali-Reza Anghaie 2002-10-01 07:03:33 EDT
For the record, it looked garbled for me (and others I confirmed with) right 
from the first dash or underline or bold, etc. 
 
I did not have to page down once or what-not for it to garble. Just to be 
clear. I don't know what hosting@j2solutions experienced. 
 
Cheers, -Ali
Comment 4 Jakub Jelinek 2002-10-01 07:31:38 EDT
This has nothing to do with glibc.
Comment 5 Ali-Reza Anghaie 2002-10-01 07:48:05 EDT
Can you please explain how this bug is related to 'less'? Seriously, I don't  
understand.  
  
Perhaps I poorly stated the bug:  
  
- By default (where more is the pager) the man pages look garbled under some  
locales.  
- PAGER=less or ln -s less more is a ~work-around~ but not a fix IMO.  
  
As I understand it the majority of locale bits are GLIBC owned and related.  
Perhaps the bug is in 'more' but certainly not 'less', or that is what I would  
think. Cheers, -Ali
Comment 6 Ali-Reza Anghaie 2002-10-01 07:49:51 EDT
(It doesn't show in the above but Jakub assigned this to 'less', I re-assigned 
it to the package owning 'more'... -Ali)
Comment 7 Ali-Reza Anghaie 2002-10-01 08:01:53 EDT
More info: 
 
[ali@damascus ali]$ locale |head -1 
LANG=en_US.UTF-8 
[ali@damascus ali]$ PAGER=more man ls 
LS(1)                            User Commands                           LS(1) 
 
 
 
NAME 
       ls b list directory contents 
 
SYNOPSIS 
       ls [OPTION]... [FILE]... 
 
DESCRIPTION 
       List  information  about  the FILEs (the current directory by default). 
       Sort entries alphabetically if none of bcftuSUX nor bbsort. 
 
       Mandatory arguments to long options are  mandatory  for  short  options 
       too. 
 
       ba, bball 
              do not hide entries starting with . 
<snip> 
 
 
[ali@damascus ali]$ PAGER=less man ls 
LS(1)                            User Commands                           LS(1) 
 
 
 
NAME 
       ls b list directory contents 
 
SYNOPSIS 
       ls [OPTION]... [FILE]... 
 
DESCRIPTION 
       List  information  about  the FILEs (the current directory by default). 
       Sort entries alphabetically if none of bcftuSUX nor bbsort. 
 
       Mandatory arguments to long options are  mandatory  for  short  options 
       too. 
 
       ba, bball 
              do not hide entries starting with . 
<snip> 
 
I must've tried 'less' after I already changed locale. Because it does NOT 
(BIG MISTAKE ON __MY__ PART) fix the problem. It just looks different (bolds 
work but all else remains the same as 'more'). 
 
Furthermore I just tried using nroff to view uncompressed man page files. Same 
results. Gobley-gook. So I don't think it's as easy as just changing 'more' or 
'less'... 
 
I'll shuttup now. Let you guys work it out until you tell me otherwise. 
Cheers, -Ali
Comment 8 Ed Halley 2002-10-01 10:05:52 EDT
Ali, when you mentioned "an update to screen" fixes some of the problem here,
where are you obtaining this 'update'?  Does merely rebuilding the 'screen' from
src.rpm suffice?  Are there upstream changes to screen which RH doesn't include yet?
Comment 9 Ali-Reza Anghaie 2002-10-01 10:13:44 EDT
Compiled from tarball, 3.9.13.. didn't try the SRPM for some reason. Hrmm.  
-Ali
Comment 10 Jesse Keating 2002-10-01 11:10:12 EDT
Whoops!  My bad.  I had my xterm set to a size that was just hiding the garbled
text.  Once I resized the xterm, and re-ran the man command, I saw garbled text
right off the bad.  Please disregard my commend about the pager.
Comment 11 Airbete 2002-10-01 12:29:56 EDT
I don't know if this can help but I have seen the above behavior in konsole and xterm but NOT 
in gnome-terminal.
Comment 12 Ali-Reza Anghaie 2002-10-01 12:43:48 EDT
I'm going to guess the reason it's not seen in gnome-terminal is because of 
something related to the locale problem described here: 
 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74701 
 
Which shows some odd behavior. Cheers, -Ali
Comment 13 Ali-Reza Anghaie 2002-10-03 09:51:47 EDT
Based on the past two days in bug 74701 I'm going to encourage people to read 
the last few entries. There is some odd BASH behavior as well. 'UNICODE 
growing pains' abound. Hrmm. 
 
Nothing to do with GLIBC I can understand (but it was assigned since the 
locale files were owned and I thought they were misbehaving) but lots of 
programs are gonna have to be made UNICODE friendly. Hrmm. Anyhow, bug 74701 
has some other info. that might be interesting to those noticing a wide-range 
of behavior. Cheers, -Ali
Comment 14 Quereller 2002-10-19 14:01:12 EDT
Possible workaround for most man-pages?

change NROFF          /usr/bin/nroff -c -mandoc
into NROFF           /usr/bin/nroff -Tlatin1 -c -mandoc
against the advice:
# NROFF is defined as "groff -Tascii" or "groff -Tlatin1";
# not only is it superfluous, but it actually damages the output.
# For use with utf-8, NROFF should be "nroff -mandoc" without -T option.
Comment 15 Fred New 2002-10-25 10:41:12 EDT
With my Estonian locale, the virtual console looks fine, but when I use PuTTY to
SSH in, the minus signs and single quotation marks appear as "a" with an
"overscore".

/etc/sysconfig/ii18n:
LANG="en_US.UTF-8"
SUPPORTED="en_US.UTF-8:en_US:en:et_EE.UTF-8:et_EE:et"
SYSFONT="latarcyrheb-sun16"

Also, if I
     man man | col -b > m
     vi m
     /-
I cannot find any minus signs even though they appear.  In fact, if I continue
editing and remove all characters around a minus sign and then
     od -c m
I see
     0000000 342 210 222  \n
     0000004

Using nroff -mandoc against an uncompressed man file doesn't help anything.
Comment 16 Christian Rose 2002-10-25 10:46:33 EDT
> With my Estonian locale, the virtual console looks fine, but when I use PuTTY to
> SSH in, the minus signs and single quotation marks appear as "a" with an
> "overscore".

That's a PuTTY problem. You'll need to set "Translation" to "UTF-8" in PuTTY's
preferences.

Comment 17 Fred New 2002-10-29 06:49:25 EST
I just downloaded the latest version of PuTTY and I can find no UTF-8 in the 
translation settings.  But I re-read Marco's comments about how to use nroff as 
a workaround and it works.  That is, the following gives me what I want whether 
I route the output to more or to a file:

     cd /usr/share/man/man1
     gunzip -cd man.1 | nroff -Tlatin1 -c -mandoc

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