|Summary:||user LANG settings are ignored|
|Product:||[Fedora] Fedora||Reporter:||Sam Steingold <sds>|
|Component:||initscripts||Assignee:||Bill Nottingham <notting>|
|Status:||CLOSED RAWHIDE||QA Contact:||Brock Organ <borgan>|
|Version:||5||CC:||mharris, mitr, rstrode, rvokal|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-04-17 00:04:37 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Sam Steingold 2006-07-18 21:34:10 UTC
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 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"
Comment 1 Matthias Clasen 2006-08-04 02:00:18 UTC
Users can select a language in the gdm login screen, and make it the default for future sessions. gdm stores this information in ~/.dmrc
Comment 2 Sam Steingold 2006-08-04 03:19:43 UTC
I am NOT running xdm or gdm.
Comment 3 Ray Strode [halfline] 2006-08-04 04:13:56 UTC
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
Comment 4 Sam Steingold 2006-08-05 03:48:28 UTC
(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?
Comment 5 Sam Steingold 2006-08-05 03:50:42 UTC
since /etc/profile.d/lang.sh is in initscripts, I am changing the component.
Comment 6 Ray Strode [halfline] 2006-08-05 05:04:41 UTC
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?
Comment 7 Sam Steingold 2006-08-05 13:15:15 UTC
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)
Comment 8 Ray Strode [halfline] 2006-08-06 06:36:38 UTC
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 ?
Comment 9 Sam Steingold 2006-08-28 13:10:08 UTC
*** Bug 199324 has been marked as a duplicate of this bug. ***
Comment 10 Sam Steingold 2006-08-28 13:18:01 UTC
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?
Comment 11 Miloslav Trmač 2006-11-10 19:49:37 UTC
(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 /usr/share/doc/initscripts*/sysconfig.txt. Thanks for your report.
Comment 12 Bill Nottingham 2007-04-17 00:04:37 UTC
This is changed somewhat in the current rawhide development trees - LANG is not necessarily overridden if it's already set. Please test.