Package: bash
Version: 3.1-4
In Debian etch, the following lines appear in ~/.bash_profile:
# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH="${HOME}"/bin:"${PATH}"
fi
If the user logs in from a text-mode screen, .bash_profile executes
and $PATH is modified correctly.
But if the system starts xdm or gdm during start-up, and the user
logs in from a graphic log-in screen, then starting an xterm bypasses
.bash_profile. In effect, there is no login shell. As a result, the user's
home bin directory doesn't automatically appear in the PATH as would be
expected.
A further problem with this script fragment is that there is no
export statement following the PATH= line, so the modified PATH variable
isn't inherited by a subshell (which it should be).
Libranet 2.7 solved this problem by placing the following lines in
~/.bashrc instead of ~/.bash_profile:
# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
PATH=~/bin:"${PATH}"
export PATH
fi
This solves the two problems stated above, but it has a problem of
its own. Each subshell executes these statements, so that if a subshell
starts another subshell, ~/bin is repeatedly pasted onto the front of $PATH:
echo $PATH
/home/mykrowatt/bin:/home/mykrowatt/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/game
It's not clear what the ideal solution would be. If a shell in an
xterm within a session started from a graphic login screen were to be
initialized as a login shell, it might be necessary to modify xdm, gdm, and
all similar programs so that they all behave the same way. (Actually, this
might have to be done at the beginning of every xterm started from a window
manager menu or icon. This might mean that xterm and similar programs
should start login shells if they're not called from other shells.)
Conversely, if this were to be dealt with entirely within the bash
package, only ~/.bashrc can count on executing, so it would have to test
whether ~/.bash_profile had already initialized all the shell variables, and
if not, source .bash_profile to initialize them. This would be opposite to
the way it's done now, with .bash_profile sourcing .bashrc. Both scripts
would have to be modified, and .bashrc would need to test whether some
particular variable were defined, in order to determine whether
.bash_profile had executed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
