Hide Forgot
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
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
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.
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
This has nothing to do with glibc.
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
(It doesn't show in the above but Jakub assigned this to 'less', I re-assigned it to the package owning 'more'... -Ali)
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
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?
Compiled from tarball, 3.9.13.. didn't try the SRPM for some reason. Hrmm. -Ali
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.
I don't know if this can help but I have seen the above behavior in konsole and xterm but NOT in gnome-terminal.
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
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
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.
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.
> 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.
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