[In the subject-line and presumably also in the quoted text, ‘.profile’
is shorthand for ‘/etc/profile then ~/.profile then /etc/xprofile and
then ~/.xprofile’.]
> Is there any good reason for gdm's Xsession to source ~/.profile? It
> is very contrary to the principle of least surprise: nothing else
> other than a login shell sources ~/.profile.
gdm provides login, and effectively acts as a (graphical) login shell.
In particular, I believe it's the only way that one's preferred
environment variable settings take effect in X.
The primary bug here is aliasing ls to give non-standard behaviour in
non-interactive contexts.
Anything in startup scripts that makes standard commands behave contrary
to standard behaviour (i.e. contrary to the behaviour expected by scripts)
should be conditional on being in an interactive context, which
in Bourne-like shells is typically done like so:
if [ -n "$PS1" ]; then
alias ls='ls --color=auto'
set -P
...
fi
(Furthermore, one would generally want to put this in ~/.bashrc rather than
~/.profile, so that it's available even in non-login interactive shells
such as launched by xterm or text editors or the like. Then one would
usually make sure that one's ~/.bash_profile contains
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
(which /etc/skel/.bash_profile and a new user's default ~/.bash_profile
already do).
~/.bashrc and ~/.bash_profile are specific to bash;
to get the approach to work for any POSIX shell, have .profile export
ENV="$HOME/my-shell-init" and use ~/my-shell-init instead of ~/.bashrc.
Indeed, one could have ~/.bashrc source ~/my-shell-init, or even
export ENV="$HOME/.bashrc" so long as it will never contain bashisms.)
> And [gdm's sourcing of .profile] seems to create a lot of
> hard-to-debug login problems.
What are examples of such problems that are likely to occur ?
Is it feasible for some task (possibly /etc/gdm/Xsession) to detect
the most common problems and warn about them ?
pjrm.
