Hamish wrote:
OSX's Terminal looks for .bash_profile but not .bashrc. Apple's X11 looks for
.bashrc but not .bash_profile. Solution (kludge) follows:
The terminals don't look for these files; bash does. However, exactly
which files depends upon the argument list:
A login shell is one whose first character of argument
zero is a -, or one started with the -login flag.
An interactive shell is one whose standard input and out
put are both connected to terminals (as determined by
isatty(3)), or one started with the -i option. PS1 is set
and $- includes i if bash is interactive, allowing a shell
script or a startup file to test this state.
Login shells:
On login (subject to the -noprofile option):
if /etc/profile exists, source it.
if ~/.bash_profile exists, source it,
else if ~/.bash_login exists, source it,
else if ~/.profile exists, source it.
On exit:
if ~/.bash_logout exists, source it.
Non-login interactive shells:
On startup (subject to the -norc and -rcfile options):
if ~/.bashrc exists, source it.
It appears that OSX' Terminal application starts bash as a login
shell. Whether or not xterm starts bash as a login shell depends upon
the [+/-]ls switch:
-ls This option indicates that the shell that is
started in the xterm window will be a login shell
(i.e., the first character of argv[0] will be a
dash, indicating to the shell that it should read
the user's .login or .profile).
Note that this is incompatible with -e, since the
login program does not provide a way to specify
the command to run in the new shell. If you spec
ify both, xterm uses -ls.
+ls This option indicates that the shell that is
started should not be a login shell (i.e. it will
be a normal ``subshell'').
and the loginShell X resource:
loginShell (class LoginShell)
Specifies whether or not the shell to be run in
the window should be started as a login shell.
The default is ``false.''
The general idea behind a "login" shell is that the "top level" shell
(the one which is started automatically when you log in on a terminal)
should be a login shell, but subsequent shells (e.g. those started by
typing "bash" in an existing shell, using the "spawn shell" feature in
a program, etc) shouldn't be.
The bash_profile files (/etc/bash_profile, ~/.bash_profile) are only
run for login shells, so you can do things like:
PATH="$PATH:/usr/local/bin"
export PATH
and $PATH won't end up getting ":/usr/local/bin" appended repeatedly.
Also, if you set environment variables in bash_profile, they will be
inherited by subshells; if you change them, the changes will be
inherited by subshells. OTOH, if you set environment variables in
~/.bashrc, those settings will replace any changed versions.
In general, environment variables should be set in bash_profile, while
aliases functions should be defined in bashrc.
Whether or not xterm should spawn a login shell depends to an extent
upon whether your X startup scripts (e.g. ~/.xsession or ~/.xinitrc)
source bash_profile. If they don't, then you probably need to use
"xterm -ls" or set loginShell to True, e.g. by adding:
XTerm*vt100.loginShell: True
to ~/.Xdefaults.
Alternatively, you can have ~/.bashrc source ~/.bash_profile, but only
if $SHLVL is 1, e.g.
if [ "$SHLVL" = 1 ] ; then
. ~/.bash_profile
fi
At startup, bash sets $SHLVL to one more than the value which it
inherited from its parent, or to 1 if SHLVL wasn't set. Consequently,
it will be 1 for a top-level shell and >1 for subshells.
--
Glynn Clements <glynn.clements@virgin.net>
