Carl Wenrich wrote: > echo $0 gives me "bash" > echo $- gives me "himBH"
Then bash hasn't been invoked as a login shell and therefore isn't instructed to source the .bash_profile. > If it is not a login shell then to suggest improvements it would be > necessary to know the type of system you are using and how you are > logging into it. There are many possibilities and I can't guess which > one you might be using. You didn't say in your messages. You have yet to say how are you are logging into your machine. There are many possibilities and without information it is impossible to guess. In the hope that it is helpful I will take a shot in the dark... On my HP-UX machine I log into the text console. This gives me a login shell that sources my .bash_profile. I then start X11 using 'xinit' which inherits all of the exported variables. On my Debian GNU/Linux machine I log in using GDM. Because logging in with XDM, or GDM, or KDM doesn't start a login shell I need to tell it this explicitly. I use an executable ~/.xsession file. In it I explicitly tell bash that it is a login shell which causes my .bash_profile to be sourced. Subsequent shells inherit the environment. This is what I use in my personal configuration: #!/bin/bash --login # exec x-session-manager # exec gnome-session # exec startkde exec fvwm2 Red Hat solves this problem in a better way by invoking the user session as a login shell from the system X start up scripts. By doing it that way the user doesn't need to worry about it. Last time I checked SuSE was a problem because it forced sourcing of the $HOME/.bash_profile (or was it .profile?) regardless of the user shell and then redirected all errors to /dev/null effectively ignoring them. Other systems will be similarly different. In any case I believe you have an answer to your question about why your ~/.bash_profile wasn't being sourced. It wasn't being sourced because your shell isn't invoked as a login shell and therefore shouldn't source it. Good luck! Bob
