On Thu, 17 Jun 2004 03:44:50 +0100 Michael Graham <[EMAIL PROTECTED]> wrote:
> Michael wrote: > > After much consternation I feel the need to vent about shell > > environment initialization. With the default Debian installation, > > /etc/profile and~/.bash_profile are not sourced in the X windows > > environment. Apparently this is because at no time is a login shell > > created which is necessary to trigger profile initialization. > > Although it's annoying that this is the way *dm work it is the only > sensible way to do it (at least that I've heard!) > > Think of this: The display manager is in essence a series of shell > scripts with a fancy front-end. Now each of these shell scripts must use > a certain shell (bash, sh, csh, tcsh, ksh, zsh, the list goes on) and > each user on the system could potentially be using a different shell. > > Now do you have the display manager source every possible file that > should be sourced for each possible shell? Only source the files that > should be sourced for the shell that the login manager uses? Or do you > setup a system where by the users shell is determined and the > appropriate files sourced? Ok, I'll play along just for a moment -- let's assume that what you're saying is true. Then we are faced with two choices: A) Choose bash and screw sh, csh, tcsh, or whatever-sh users B) Do nothing and continue to screw everybody If we had a vote I think I would put my paycheck on A. If someone is running something other than the default shell they shouldn't have a problem hacking their own profile. But they don't need to ... > I hope if you think about it you'll realise that it is highly > non-trivial to implement a system where no matter which shell the user > uses the dm will act in the same way. > > For instance if the dm uses a bash login shell and I have two users on > the system one using tcsh and one using bash. Then the bash user would > have his login files sourced and the tcsh user would not I'm not suggesting that you manually source any files. The login shell automatically does that for you. Look, conceptually what needs to be done is simple. The purpose of the login option of a shell is to say "Hey, I'm logging in, initialize my environment." Subsequent shells do not use the login option which is to mean "Hey, I've already initialized my environment so don't bother to do it again. I just want another shell, inherit the environment from the parent." So all we have to do is detect when a user is logging in and exec their default shell with the login option. Debian does that when you ssh in or login on the console but not when you login with X. Where would we do that? Well let's review the process. Let's say your using gdm (but it's very similar for each login manager). Gdm calls scripts to be executed by root like /etc/X11/gdm/Init/Default for calling xmodmap, setting kbdrate, or /etc/X11/gdm/PostSession/Default mounting a home drive, etc. Then it switches to the user with setuid and calls scripts to be executed as the user to like /etc/X11/gdm/Xsession which calls /etc/X11/profile.d/ (or whatever it's called) which eventually exec's the session manager like say /usr/bin/wmaker possibly via ~/.xsession. Now if we exec the session manager at the very end we don't have a lot of choices. We have to launch our login shell there. Now I'm on a RH 7.3 system right now and I've never had this profile issue on RH systems so if I look at their scripts I see: #!/bin/bash ... lots of stuff ... # otherwise, take default action if [ -x "$HOME/.xsession" ]; then exec -l $SHELL -c "$HOME/.xsession" There are a lot of other lines that look like this but this one illustrates quite clearly how RH handles this. I'm not terribly familiar with exec options of bash but I'm willing to bet it has something to do with the login option or has the equivalent effect. You guys really should fix this problem. It's quite a wart. Mike -- Greedo shoots first? Not in my Star Wars. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]