Bug#454097: gdm sourcing .profile, and using `alias' in .profile

[Chris Lesniewski-Laas]

On Wed, Jan 16, 2008 at 01:59:56PM +1100, Peter Moulder wrote:
> > 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.

I understand your position, but my expectation would not be that environment
variables in .profile will be loaded by my X display manager.  The file
.profile is only documented in the bash manpage, as far as I know; .profile is
not mentioned in the gdm manpage.

I've always started a login shell in my X window manager for this reason.  I am
not sure what other people do.  Since sourcing .profile is a recent change, I'm
sure other people have similar techniques.

> The primary bug here is aliasing ls to give non-standard behaviour in
> non-interactive contexts.

To clear up any confusion, my problem was not ls-related (although the other
posters in this thread appear to have had various similar issues).  My problem
was that a workaround I installed (years ago) to deal with systems that don't
respect chsh ended up interacting badly with gdm's new behavior.

> Anything in startup scripts that makes standard commands behave contrary
> to standard behaviour (i.e. contrary to the behaviour expected by scripts)

Startup scripts are not supposed to be sourced by shell scripts.  (Except
$BASH_ENV, .zshenv, and so on.)

> (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.

Sometimes one wants behavior (e.g. motd, w) that is only run in interactive
login shells.  It's not clear how one is expected to do that.

> > 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 ?

I was referring to the other problems that people seem to have encountered in
the thread.  I don't have any more information than that.

> Is it feasible for some task (possibly /etc/gdm/Xsession) to detect
> the most common problems and warn about them ?

Perhaps early termination of the xsession script could be detected and reported
as such, including where it terminated?  Unfortunately, in my case, the
.xsession-errors file didn't contain anything useful.  "set -x" at the
beginning would give sufficient information, but might be too verbose for most
users.

Cheers,
Chris