Hide Forgot
I selected English (US) as the locale for 8.0 install. I got # cat /etc/sysconfig/i18n LANG="en_US.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16" When I ssh into 8.0 from a 7.3 machine, # man init displayed funny characters. If I do # LANG="en_US.iso885915" 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). Cheers, -Ali
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).. ed@halley.cc 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. ;-) Cheers, -Ali
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 also. 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 environment. 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.