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. ***