Red Hat Bugzilla – Bug 199323
user LANG settings are ignored
Last modified: 2014-03-16 23:00:39 EDT
Description of problem:
my linux (fc5) box is shared by several people,
so it runs at runlevel 5 with several virtual consoles.
a user finds an unused virtual console,
logs in and types at the bash prompt "startx -- :1"
or "startx -- :2" etc, depending on which server is available.
the users switch between their X/gnome desktops using Ctrl-Alt-F.
now, the "global" setting for LANG in /etc/sysconfig/i18n is
which is what "most" users want.
Now, the dissident users that want to use a different locale try to set LANG
in their ~/.bash_profile and, indeed, after they login in the virtual console,
they observe the correct value of LANG:
$ echo $LANG
alas, when they open a gnome-terminal in X, the value of LANG is reverted to
the system-wide default "en_US.UTF-8".
So, how can different users use different locales?
Steps to Reproduce:
3.login on a virtual console
4.echo $LANG ==> "BAR"
7.echo $LANG ==> "FOO"
LANG in xterm is "FOO"
LANG is xterm is "BAR"
Users can select a language in the gdm login screen, and make it the default
for future sessions. gdm stores this information in ~/.dmrc
I am NOT running xdm or gdm.
Are they putting it in ~/.profile or ~/.bash_profile ?
Note bash will only source one of those files (~/.bash_profile) if both exist.
If your users are putting it in ~/.bash_profile and they have
if [ -f ~/.bashrc ]; then
at the top of the file, then they must put it after that.
The language is probably getting reset by
(In reply to comment #3)
> Are they putting it in ~/.profile or ~/.bash_profile ?
> Note bash will only source one of those files (~/.bash_profile) if both exist.
come on! please read the original report: the LANG variable IS SET
after the login at the virtual console.
it gets reset when I run startx
> The language is probably getting reset by
so it appears that the users must put their settings i18n in ~/.i18n -
maybe /etc/profile.d/lang.sh should test if LANG is already set before
resetting it by sourcing /etc/sysconfig/i18n?
since /etc/profile.d/lang.sh is in initscripts, I am changing the component.
Oh, I think i know what's going on...
Note when you start a gnome-terminal instance, it starts an interactive,
non-login shell, and when you login from a virtual console it starts an
interactive, login shell.
/etc/profile.d/lang.sh only gets run in the case of a non-login shell.
On the other hand, .bash_profile *doesn't* get run when you start a non-login shell.
.bashrc will get run if you start an interactive shell though.
So, if you make sure
is at the bottom of .bashrc (not above the bit that sources /etc/bashrc), I
think it should work. Using .i18n is better of course.
Does that work okay?
yeah, OK, but it would still be better if /etc/profile.d/lang.sh did not source
/etc/sysconfig/i18n when LANG is already set (it's OK to source ~/.i18n)
Possibly. That might fix your problem, too.
When you startx, your X session is started through a login shell, so
~/.bash_profile gets read (and your user's language settings get set).
Then when you start a gnome-terminal window, /etc/profile.d/lang.sh gets run and
resets LANG. So if we make the change your suggesting, we won't reset LANG and
things should just work.
On potential problem is that LANG might get set to C or something early in the
boot process and break things for people who don't set LANG in their
Can you do some experiments and see if your change
1) fixes your problem
2) doesn't break things for other people
*** Bug 199324 has been marked as a duplicate of this bug. ***
one solution would be:
1. scripting: do NOT run /etc/profile.d/lang.sh if LANG is already set.
2. gui: there should be a user setting specifying LANG. this gui front-end may
write ~/.i18n but it MUST first check that ~/.profile and ~/.bash_profile do NOT
set LANG already so that ~/.i18n is not ignored as mandated by .
where is the ~/.i18n hack documented?
(In reply to comment #10)
> 1. scripting: do NOT run /etc/profile.d/lang.sh if LANG is already set.
That would break ~/.i18n completely, it needs to override the system default LANG.
> 2. gui: there should be a user setting specifying LANG.
We have such a GUI included in gdm.
> but it MUST first check that ~/.profile and ~/.bash_profile do NOT
> set LANG already so that ~/.i18n is not ignored as mandated by .
Checking whether a general program does or does not set LANG is probably
infeasible, although some kind of hack could solve most cases.
> where is the ~/.i18n hack documented?
Currently nowhere. I have added a reference to it to the same place
/etc/syscofnig/i18n is documented, which is
Thanks for your report.
This is changed somewhat in the current rawhide development trees - LANG is not
necessarily overridden if it's already set. Please test.
Whatever was changed here for this bug, might have inadvertently created bug
#372151 which I'm investigating currently.