Red Hat Bugzilla – Bug 6500
How to fix the blinking ADs displayed instead of hyphens..?
Last modified: 2008-05-01 11:37:52 EDT
Very trivial, but... I have long been plagued by glowing ADs in angle brackets when reading man pages. Quite by chance, I found this in 'man man' as a bug, with a suggested fix of setting the LESSCHARSET variable to 'latin1' 'man less' makes it look a bit more complicated, but this certainly works for me. Is it possible to put this in the /etc/profile? Or, if this would cause trouble for people using other languages and character sets (I don't understand all the references to locale but I gather that that's what it's all about), is there some other way to deal with this?
The problem is indeed the "less" package not groking latin1 by default. Putting export LESSCHARSET=latin1 in /etc/profile is a good solution. Another solution is to configure the man package to NOT use latin1, by editing /etc/man.config and changing the lines with -Tlatin1 to -Tascii. Likely won't get some of the pretty latin1 characters displayed though. I recommend fixing the "less" package default, or changing /etc/profile.
the real fix is to set your locale if you don't want to use POSIX/C/ASCII. If I do LANG=en_US man man, the dashes get removed.
This isn't just man & less agreeing on character sets, it's everything on the system. For example, M-x man in emacs. So, setting LESSCHARSET isn't a complete solution. The LANG=en_US fix is more global, but a) why should /etc/man.config be arbitrarily deciding to use -Tlatin1 instead of -Tascii (as it was in the version in RH5.2), b) does setting LANG get *all* text handling programs to agree, and c) can you elaborate more on the effects of setting LANG=en_US? Your comment about setting it "if you don't want to use POSIX/C/ASCII" makes me a little nervous. Also, is this going to be corrected in RH6.2, and if so, is it going to be via setting LANG by default in /etc/profile?
*** Bug 8574 has been marked as a duplicate of this bug. ***
echo LANG=en_US > /etc/sysconfig/i18n That _is_ the proper fix. And yes, it will be fixed in the next release
*** Bug 10185 has been marked as a duplicate of this bug. ***