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]
