Michael wrote: > > > > 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 ...
Of course you can do that it's just that at the moment most the scripts are sh not bash but it could be done. > 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." I agree, conceptually it's simple, but what I'm not sure of is the implementation. > 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. > > <snip!> > > 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. But in this case you exec'ing the users own .xsession so sourcing .profile isn't a problem, since the user should do it in the .xsession (either manually or by making it a login session) so you just do exec ~/.xsession and let the user deal with it! The problem occurs when the user doesn't have a .xsession (or doesn't want to use it!) then the system has to exec the correct shell as a login to run the window manager that they wanted. exec -l $SHELL -c "window-manager-bin" And this means that the user is logged in twice (once for the shell and once for X) and is running a shell for no reason other that to source a file. Personally I would like to see a ~/.X_profile that is source by the dm (so currently it would have to be valid sh script, but this would change if the shell of the dm changed). People who use the same shell as the dm could symlink it to ~/.profile if they wanted. We then have a system where by a X login sources a file that the user can use to setup paths (or whatever) without having to worry about there ~/.profile being incompatible with the dm's shell or have to exec an extra shell. -- OoberMick (At the Mensa society meeting) Lisa: Now next week is our "state of the city" address. Has everyone finished their proposals. CBG: Well first of all I've a plan to eliminate obesity in women. They Saved Lisa's Brain (Episode AABF18)
pgp5isuK2RC9N.pgp
Description: PGP signature