Description of Problem: When a gdm session is started, the bash config files are not being sourced. Version-Release number of selected component (if applicable): xinitrc-3.27-1 How Reproducible: every time Steps to Reproduce: 1. put XIM=skkinput in "~/.bashrc" 2. start a new gdm session 3. printenv XIM Actual Results: XIM is not set. Expected Results: XIM should have been set. Additional Information: This is a regression relative to RHL 7.3. With zsh as one's login shell, this problem does not occur. This bug means that in particular it is next to impossible for bash users to pass XIM say to /etc/X11/xinit/xinitrc.d/xinput to select an alternative IM or pass commandline options to it.
gdm is configurable aparently on wether or not a login shell is used or not. I do not recall making any changes to xinitrc package that would cause this to happen since 7.3. Has anyone else changed anything?
Is the configuration done at build time? I don't see any relevant options in gdm.conf or anywhere in /etc/X11/gdm in fact. Of course the version of gdm changed changed since 7.3. Well, zsh works fine, but bash doesn't.
.bashrc has nothing to do with login shell or not, it has to do with whether the shell is interactive. I'm not sure the shell run on login counts as interactive, it doesn't seem like it would; to run stuff on login you would want to use .bash_profile.
Still, this is odd that it worked in 7.3 and didn't now... people will probably expect their configs to work the same.
well, what makes a shell interactive? isatty(stdin)?
Isn't it more to do with login shell vs non-login shell? For a non-interative shell "bash --login" should read ".bash_profile", otherwise by default it doesn't read anything (unless BASH_ENV is set). I suspect the user's shell isn't being called as a login shell somewhere (gdm? gnome-session?) [zsh by default always sources .zshenv, explaining why it is not affected by this problem so badly.]
This bug looks like http://bugzilla.gnome.org/show_bug.cgi?id=77335
(Reassigning to gdm, since it looks closer to the problem.)
.bashrc has nothing to do with login shell or not. We do the login shell stuff in the Xsession script not in gdm, so should be getting a login shell for all users including tcsh users. So basically http://bugzilla.gnome.org/show_bug.cgi?id=77335 should not impact our setup. .bashrc is keyed purely off of interactivity... the login shell _isn't_ interactive, so I'm awfully inclined to NOTABUG this and say 7.3 was busted.
From the bash manual: What is an Interactive Shell? ----------------------------- An interactive shell is one started without non-option arguments, unless `-s' is specified, without specifiying the `-c' option, and whose input and output are both connected to terminals (as determined by `isatty(3)'), or one started with the `-i' option. An interactive shell generally reads from and writes to a user's terminal.
I am in full agreement that the shell is not interactive. What prompted me to file this bug is that it currently doesn't seem possible to pass environment variables to /etc/X11/xinit/xinitrc.d/* in a gdm session. In particular this means that Japanese users won't be able to use skkinput in gdm session instead of kinput2 (by setting "XIM=skkinput" in their .bashrc file say. So is this a xinitrc package bug after all? It looks like the xinitrc.d/ files should really be sourced after Xsession exec's the login shell.
I'm also in full agreement about the .bashrc, though havoc got one thing wrong, gdm DOES run a login shell session and in it it executes the Xsession script so currently /etc/profile is run twice. But that's irrelevant since I'm planning (and the kdm guy is also planning) to change the way this works 1) gdm/kdm will neither run a login shell themselves 2) the standard Xsession script will not be run in login mode bash 3) the standard Xsession will source /etc/profile, .profile, /etc/xprofile and .xprofile. So in the future you would put such stuff in ~/.xprofile or /etc/xprofile
Jens - I'm not sure how /etc/X11/xinit/xinitrc.d/ works or what it's supposed to do, so I'm not sure I can answer that question. Can't you put things in /etc/profile.d? George - ah, but we haX0rd our gdm to not run the shell as a login shell. ;-)
Good point Havoc. I totally missed the interactive/non-interactive thing. Indeed, .bashrc should only be sourced for interactive shells, of which a gdm login isn't. This is documented on the bash manpage. I think we can now close this NOTABUG. Hacking it to fit the requested behaviour would be bad IMHO.
hp> ah, but we haX0rd our gdm to not run the shell as a login shell. ;-) Isn't this the cause of the problem then?
No, the Xsession script already does a login shell. We removed it from gdm so you'd only read .profile and /etc/profile.d one time.
Yes, but I think the fix to bug 66486 would have been better made in Xsession, than in slave.c. That would fix this problem afaict. gdm-2.4.0.7-dbllogin-66486.patch [Fixing summary to be more precise]
Well actually redhat solved it more correctly then I did. But the most correct would not be using the -login, but some sort of behaviour as I outiled above (which gdm will use, well will ship Xsession script that will do that, or better yet this will be a common small package between kdm/gdm). I didn't want to do such a change within the current release of gdm just in case someone is depending on the current gdm behaviour. In any case to solve your current problem, if you want something done only in a gdm session, you can use the GDMSESSION env var. So you'd still add it to profile but surround it by something like: if [ -n "$GDMSESSION" ]; then ... fi or some such. GDMSESSION will always be set to the name of the session picked by the user (in the future it may be a full path of a script to execute, but future setup will be saner anyway).
Another workaround is to have the xinput script read "/etc/sysconfig/i18n" and "~/.i18n", that would solve the problem (and should also already work in RHL 7.3). Attaching a patch to that effect (new lines just copied from "/etc/profile.d/lang.sh"). Does it look ok, Mike?
(Thought I had already added Mike to the CC list...)
Created attachment 74826 [details] patch to make xinput source i18n config files for XIM, etc
Errm, that patch doesn't work for startx sessions unfortunately. Back to the drawing board...
Well, actually if we check that XIM isn't defined before sourcing the i18n config files, I think the behaviour wrt XIM is as good as in RHL 7.3.
Having the i18n config files sourced appropriately in xinput seems to involve too many assumptions. It still seems to me that the only right way to fix this, is to revert the login shell patch on slave.c in gdm, but anyway...
Jens, you aren't explaining rationale for what you're saying, so it is hard to know why you are reaching the conclusions you are. Here is the story: - all user logins should end up reading /etc/profile.d or /etc/profile. for a console login this happens when you first log in, for gdm it happens in Xsession - if you want all user logins to get a particular env variable, you would normally put it in /etc/profile.d So what is special/different about XIM? When do you use xinitrc.d instead of profile.d?
I guess xinitrc.d has been used until now, because its scripts are only to be run when starting an X session and at no other time. [I guess they are the equivalent of the /etc/xprofile that George mentioned.] In 7.3 and earlier I believe, gdm ran Xsession from a login shell and so the users' env was present when xinitrc.d/* were sourced by Xsession. In particular this meant that users could choose their own XIM client by setting XIM or XIM_PROGRAM in their shell rc file. This is not possible now. The only other solution I see is moving the sourcing of xinitrc.d/* out of Xsession and into say gnome-session, and whatever the KDE equivalent is, or a wrapper shell of those. In the longer term we are probably going to do all this completely differently anyway, so it is just a problem now really.
The minimally non-intruisive thing to me seems to be to add if [ -f /etc/profile.d/lang.sh ] ; then . /etc/profile.d/lang.sh fi to /etc/X11/xinit/xinitrc.d/xinput This makes: Adding: LANG=ja_JP XIM=skkinput Work for me for both startx and gdm. I guess it makes: XIM=skkinput startx *Not* work, but I don't think we should care about that.
xinitrc-3.29 adds the sourceing of lang.sh to xinput. This (in my testing) allows setting the input method by adding XIM=skkinput into ~/i18n. While it's unfortunate that the previous method of setting it putting the setting into ~/.bashrc doesn't work, I think the new method also makes sense (that's where you configure your language, after all), and any other change would be far too intrusive at this point. (Putting this bug into the MODIFIED state for Jens to confirm when he wakes up)
When GDM_LANG is set it does include the default codeset. So for example if you select simplified chinese GDM_LANG is set to zh_CN, not the normal LANG value of zh_CN.GB18030. At least chinput the Simplified Chinese input method is depandant on knowing what the locale codeset is, so it fails to start. We have never not specified the codeset in the LANG variable, so full impact is unknown. We can either get gdm to include the codeset when it sets GDM_LANG or revert this patch. I think getting gdm to include codeset is best. ja_JP.eucJP ko_KR.eucKR zh_TW.Big5 zh_CN.GB18030
Could you file this separately, so we can close this bug? It's not related. (I really think that if chinput has a bug where it is looking at the string value of the locale rather than the locale name, it should be fixed.)
Confirmed fixed in xinitrc-3.29-1. Thank you. FWIW I also agree that using i18n makes at least as much sense as bashrc. i18n also works in RHL 7.3. Well, this is basically the change that was discussed above yesterday.