Solved: Problem with bash login.

[Steven W. Orr]

On Tuesday, Aug 1st 2006 at 15:04 -0400, quoth Paul Lussier:

=>"Steven W. Orr" <steveo at syslang.net> writes:
=>
=>> Thanks to everyone who responded. Setting up a .xsession file is the 
=>> correct solution to the problem. The quirk is that the file must be 
=>> executable even though it is sourced in.
=>
=>So, what do you put in your .xsession file?  Everything that's in
=>.bash[rc,_profile]? or do you just source the correct file from there?
=>
=>If the latter, which is the correct one again?


It turns out that I was a bit premature in saying that I have it all 
working.

I have a machine running gdm which runs the .bash_profile (and not the 
.xsession file) if you set gdm to run a kde session. If you run a gnome 
session it runs neither. None of the machines I am monkeying with have kdm 
installed so I don't know how that would behave. Other machines 
(supposedly exactly the same) behave differently. Some do run the 
.xsession file and some don't, with dependancies on a collection of 
factors, not all of which are understood (or even rational).

The answer to the question above is that a .xsession *should* be able to 
source a .bash_profile, but be aware that some environments are running 
that .xsession in a language that's not going to be bash. (Of course in 
Linux, bash is going to work.) Also note that the .xsession must be 
executable even though it will be sourced.

At login, you should run your .bash_profile and your .bash_profile should 
source in your .bashrc . A .bashrc should be run by any subshell and 
should not set envvars (as has been discussed here). The .bashrc should 
test to see if it is interactive by looking at PS1 to see if it's null. If 
PS1 is null then the PATH (or possibly other envvars) should be set to 
deal with remote commands being able to succeed.