Bug 74832 - Bad LANG?
Summary: Bad LANG?
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts   
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
: 70523 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-01 23:30 UTC by hjl
Modified: 2014-03-17 02:31 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-04 21:10:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A patch for remote access (834 bytes, patch)
2002-10-02 20:00 UTC, hjl
no flags Details | Diff

Description hjl 2002-10-01 23:30:40 UTC
I selected English (US) as the locale for 8.0 install.
I got

# cat /etc/sysconfig/i18n

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.

Comment 1 Ali-Reza Anghaie 2002-10-02 00:43:46 UTC
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

Comment 2 hjl 2002-10-02 03:03:03 UTC
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.

Comment 3 Richard Allen 2002-10-02 14:10:36 UTC
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.

Comment 4 Michael Fulbright 2002-10-02 16:08:38 UTC
This appears to be a bug with man.  The LANG line is correct.

Comment 5 hjl 2002-10-02 16:30:36 UTC
I want to stress this. This bug is when you login to RedHat 8.0
remotely from other non-RedHat 8.0 machines.

Comment 6 Ali-Reza Anghaie 2002-10-02 16:46:49 UTC
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

Comment 7 Mike A. Harris 2002-10-02 17:43:18 UTC
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.

Comment 8 hjl 2002-10-02 17:55:12 UTC
I tried ssh into 8.0 inside xterm and VC from RedHat 7.3.
The results are the same.

Comment 9 Mike A. Harris 2002-10-02 19:11:11 UTC
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.

Comment 10 hjl 2002-10-02 19:20:22 UTC
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.

Comment 11 Ali-Reza Anghaie 2002-10-02 19:34:41 UTC
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

Comment 12 hjl 2002-10-02 20:00:47 UTC
Created attachment 78165 [details]
A patch for remote access

Comment 13 hjl 2002-10-02 20:02:34 UTC
I uploaded a patch which works with zsh. A similar
change can be made to lang.csh.

Comment 14 hjl 2002-10-02 23:14:12 UTC
*** Bug 70523 has been marked as a duplicate of this bug. ***

Comment 15 Bill Nottingham 2002-11-12 06:29:03 UTC
unilaterally disabling UTF-8 for remote terms is not the answer.

Note You need to log in before you can comment on or make changes to this bug.