Red Hat Bugzilla – Bug 74832
Last modified: 2014-03-16 22:31:14 EDT
I selected English (US) as the locale for 8.0 install.
# cat /etc/sysconfig/i18n
When I ssh into 8.0 from a 7.3 machine,
# man init
displayed funny characters. If I do
which is used in 7.3, "man init" works fine.
Please look at bug 74706. You can set LANG to "en_US" for the latin set... You
might be intersted in bug 74701 as well. I'd close the bug as dupe (end user).
They are related, but not the same. I'd like to
keep it open and verify the fix separately when
it becomes available.
BTW, it also happens with telnet and rlogin.
You should try to use Icelandic in a mixed RH8.0 and anything else environment.
Icelandic has 22 special characters (22 counting upper and lower case). If I
connect to another machine (be it HP-UX, Solaris, RH <= 7.3 and etc) everything
gets very ugly.
This appears to be a bug with man. The LANG line is correct.
I want to stress this. This bug is when you login to RedHat 8.0
remotely from other non-RedHat 8.0 machines.
It's not neccesarily with man. Please look at bug 74706. It can happen
remotely and locally (notice that there is a note indicating gnome-terminal
people don't seem to have the problem BUT that is also somewhat discussed in
but 74701).. firstname.lastname@example.org and I have also experienced the problem logging in
between two Psyche machines. So I think there are many potential symptoms of
the ~same~ nature/bug.
Nroff shows the problems as well. In any case I trust RH will track down the
best way to solve it across-the-board.
The LANG line is certainly correct I just think we're seeing 'growing pains'
as we move into UNICODE. The LANG settings are just a work-around lest we want
to go the way of the dinosaurs. ;-)
hj, are you ssh'ing to the 8.0 box from inside an xterm (or other terminal),
or are you ssh'ing from a VC? If via xterm or similar, could you also test
it via VC? This is just for data gathering.
I tried ssh into 8.0 inside xterm and VC from RedHat 7.3.
The results are the same.
If the remote application is using UTF-8 encoding for display, then the
local app displaying it (wether the local app is on the same machine,
or is a remote xterm/gnome-term/console/etc.) needs to be set to UTF-8
So, I don't really see this as a bug personally. It's just that the
remote machine, being RHL 8.0 is defaulting to using UTF-8 for default
encoding, and the machine that is connecting in, is not using UTF-8,
so they have a communication problem. Not a bug, just 2 configurations
which are mutually incompatible.
The only solution is to reconfigure the remote machine to not use UTF-8
by default, and use the encoding that the other machines connecting
to it use instead, or to reconfigure the other machines to also use
UTF-8. Keep in mind however, that Red Hat Linux 8.0 is the first release
of Red Hat Linux that officially supports UTF-8. Using UTF-8 in Red
Hat Linux 7.3 may or may not work.
What would be a useful workaround for this problem which many end users
will experience, and think is a bug (but isn't really), would be if
ssh would propagate the LANG variable across to the remote machine. Then
your local encoding would automatically override the remote default
This would require openssh's default behaviour to be changed however.
IMHO, this bug isn't a "man" bug. I'd consider this particular bug
as NOTABUG, or perhaps reassign it to openssh to see if Nalin might
consider having LANG propagate over ssh sessions in future Red Hat
Linux 7.x openssh erratum. Not sure if changing the behaviour of
ssh in this respect would violate a standard or somesuch though.
In short... it's just Unicode growing pains.
It is not just ssh. All remote accesses, IP or serial, from
non RedHat 8.0 machines may have this issue. It has very
little to do with ssh and more to do with the terminal
from which the access is initiated.
Mharris and I discussed this. And he cleared up a few things for me and I
re-tested. I indeed had the problem between two RH 8.0 boxes. BUT one of the
was set en_US at boot and not UTF-8 (oddly just an 'export LANG' to UTF-8
didn't fix it, X had to be restarted (74701?).
Perhaps patches to the major programs to generate a warning on conflicting
LANG settings would be a good idea. Upstreams should be asked for Unicode
support ~but~ if the server is classic Latin and the client is Unicoe it'll
still garble. Hrmm. Good luck though 8.x growing into Unicode. Hrmm. -Ali
Created attachment 78165 [details]
A patch for remote access
I uploaded a patch which works with zsh. A similar
change can be made to lang.csh.
*** Bug 70523 has been marked as a duplicate of this bug. ***
unilaterally disabling UTF-8 for remote terms is not the answer.