Hide Forgot
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[789]. now, the "global" setting for LANG in /etc/sysconfig/i18n is LANG="en_US.UTF-8" 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 ru_RU $ 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? How reproducible: always Steps to Reproduce: 1./etc/sysconfig/i18n:LANG="FOO" 2.~/.profile:export LANG="BAR" 3.login on a virtual console 4.echo $LANG ==> "BAR" 5.startx 6.xterm 7.echo $LANG ==> "FOO" Actual results: LANG in xterm is "FOO" Expected results: 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 . ~/.bashrc fi at the top of the file, then they must put it after that. The language is probably getting reset by /etc/profile.d/lang.sh
(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 > /etc/profile.d/lang.sh so it appears that the users must put their settings i18n in ~/.i18n - interesting. 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 export LANG=ru_RU.utf8 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 ~/.bash_profile. 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 [1]. 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 [1]. 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 /usr/share/doc/initscripts*/sysconfig.txt. 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.