Menu
▾
▴
#743 csh and i18n on OSCAR nodes
open-accepted
5
2005-12-14
2005-11-08
No
The /etc/profile.d/less.csh script expects to
find /etc/sysconfig/i18n. If its missing, as it is on every
OSCAR compute node, ssh or login generates an error.
According to Red Hat, their installer creates this file, so the
issue occurs only with non-standard installs, like SiS.
Ive fixed the issue with cpush /etc/sysconfig/i18n after
install and by updating the oscarimage.
It would be nice to have the this file automatically copied
from the head node to any new client image. I think it's safe
to assume that the language settings on the compute nodes
can be identical to the head node.
Logged In: YES
user_id=288102
Can you please post the error msg. I just tried to recreate
this under Fedora Core 4, with compute nodes *not* having
this /etc/sysconfig/i18n and my user's default shell is
'/bin/csh'.
All i got was the standard xauth error,
finger foobar
Login: foobar Name: FooBar
Directory: /home/foobar Shell: /bin/csh
Never logged in.
No mail.
No Plan.
[foobar@headnode ~]$ whoami
foobar
[foobar@headnode ~]$ ssh oscarnode1
Warning: No xauth data; using fake authentication data for
X11 forwarding.
Last login: Mon Nov 21 15:52:25 2005 from headnode
Logged In: YES
user_id=288102
Need more info/response to reproduce problem.
Logged In: YES
user_id=505737
Can we get the error message? We can't seem to reproduce this.
Logged In: YES
user_id=847865
The error occurs in /etc/profile.d/less.csh)
It fails with the error:
LANG: Undefined variable.
I quick look shows that $LANG is set
in /etc/sysconfig/i18n. I only use RHEL 3 and 4 for
clusters.
How is $LANG being defined on your Fedora nodes, or is
less.csh non-existent?
Logged In: YES
user_id=847865
The error occurs in /etc/profile.d/less.csh)
It fails with the error:
LANG: Undefined variable.
I quick look shows that $LANG is set
in /etc/sysconfig/i18n. I only use RHEL 3 and 4 for
clusters.
How is $LANG being defined on your Fedora nodes, or is
less.csh non-existent?
Logged In: YES
user_id=288102
# Below info from FC4/x86 system
This "VARNAME: Undefined variable" is the same thing I ran
into for my perl5lib-profile-oscar pkg. Ironically I
discovered my bug when I was trying to reproduce your bug. :)
(See also: Bug#1364170)
I definately don't see the LANG error in my tests on FC4. I
just looked and there does not appear to be a reference to
LANG on the FC4 from '/etc/profile.d/less.csh'.
root# cat /etc/profile.d/less.csh
# less initialization script (csh)
if ( -x /usr/bin/lesspipe.sh ) then
setenv LESSOPEN "|/usr/bin/lesspipe.sh %s"
endif
This '/usr/bin/lesspipe.sh' is a big nasty shell script but
doesn't contain a reference to LANG either,
root# grep -ic LANG /usr/bin/lesspipe.sh
0
root# grep -ic LANG /etc/profile.d/less.csh
0
It appears that the LANG value is setup by a standalone
profile.d scripts,
/etc/profile.d/lang.{csh,sh}
And no other references are made directly from other
profile.d scripts,
root# grep -ic LANG /etc/profile.d/*
/etc/profile.d/00-modules.csh:0
/etc/profile.d/00-modules.csh.rpmbuild:0
/etc/profile.d/00-modules.sh:0
/etc/profile.d/00-modules.sh.rpmbuild:0
/etc/profile.d/apitest.csh:0
/etc/profile.d/apitest.sh:0
/etc/profile.d/c3.csh:0
/etc/profile.d/c3.sh:0
/etc/profile.d/colorls.csh:0
/etc/profile.d/colorls.sh:0
/etc/profile.d/glib2.csh:0
/etc/profile.d/glib2.sh:0
/etc/profile.d/gnome-ssh-askpass.csh:0
/etc/profile.d/gnome-ssh-askpass.sh:0
/etc/profile.d/krb5.csh:0
/etc/profile.d/krb5.sh:0
/etc/profile.d/lang.csh:11
/etc/profile.d/lang.sh:14
/etc/profile.d/less.csh:0
/etc/profile.d/less.sh:0
/etc/profile.d/oscar_home.csh:0
/etc/profile.d/oscar_home.sh:0
/etc/profile.d/perl5lib-profile-oscar.csh:0
/etc/profile.d/perl5lib-profile-oscar.sh:0
/etc/profile.d/ssh-oscar.csh:0
/etc/profile.d/ssh-oscar.sh:0
/etc/profile.d/vim.csh:0
/etc/profile.d/vim.sh:0
/etc/profile.d/which-2.sh:0
Does that info help?
Logged In: YES
user_id=288102
I checked and FC4 also sets LANG in '/etc/sysconfig/i18n'.
I removed that file from the system and tried my test again
(becoming a users with default shell set to '/bin/csh') and
didn't see any errors (other than my PERL5LIB error, which I
fixed).
Also, the LANG value is indeed *not* set. :)
root# su - tjntest
tjntest$
tjntest$ echo $LANG
LANG: Undefined variable.
tjntest$ ls -l /etc/sysconfig/i18n
ls: /etc/sysconfig/i18n: No such file or directory
So looks like this is definately i18n related and possibly
specific to RHEL's? So my testing isn't much help from FC4 :)
Logged In: YES
user_id=288102
SUMMARY:
Restated, on your system, less.csh makes use of LANG and on
the compute nodes this value is not set b/c OSCAR+SIS
doesn't setup the '/etc/sysconfig/i18n' file.
BTW, we just checked on CentOS 4.1 and didn't have the LANG
error but did confirm if something similar existed it would
be annoying b/c it would show up in all cexec cmds for the
user with 'csh' as his shell. ;)
Logged In: YES
user_id=879102
I recommend a docfix for 4.2.1 and we will copy
/etc/sysconfig/i18n to the image in trunk (5.0).
Jeremy, on my test system (RHEL4u2 x86, workstation
install), I have no problems when I ssh as a user using csh.
Did you install anything out of the ordinary that might
have triggered this? This is what my
/etc/profile.d/less.csh looks like:
# less initialization script (csh)
if ( -x /usr/bin/lesspipe.sh ) then
setenv LESSOPEN "|/usr/bin/lesspipe.sh %s"
endif
Logged In: YES
user_id=847865
Based on the comments in the Red Hat Bugzilla item, they
likely have fixed the problem. This would explain why
Fedora Core 4 and RHEL4U2 are OK.
The less script from RHEL3U5 looks like this:
# less initialization script (csh)
if ( -x /usr/bin/lesspipe.sh ) then
setenv LESSOPEN "|/usr/bin/lesspipe.sh %s"
endif
if ( $?LC_ALL ) then
setenv LANGVAR $LC_ALL
else
setenv LANGVAR $LANG
endif
if ( `echo $LANGVAR | cut -b 7- | tr -
s "[:lower:]" "[:upper:]"` == "EUCJP" ) then
setenv JLESSCHARSET japanese-euc
else
if ( `echo $LANGVAR | cut -b 7- | tr -
s "[:lower:]" "[:upper:]"` == "EUCKR" ) then
setenv JLESSCHARSET korean
endif
endif
$LC_ALL is not usually set and $LANG is set in i18n. Since
i18n is missing on nodes, csh generates one error per node
every time c3 utilities are used.
The fix looks good.
Logged In: YES
user_id=879102
Okay this is definitely a doc fix then. However, we need to
check Fedora Core 2 and 3 to see if it needs to be
documented on those systems too. Or we can just say "on
some Linux distrbutions..."
Logged In: YES
user_id=879102
Docfixed in branch, moving to group 5.0.