lightdm sources .profile

See also Bug #1468834.

.xsession is sourced within /bin/sh, not /bin/bash. It wouldn’t make sense to source .bashrc from it (unless you happened to write a .bashrc that doesn’t use any bash features).

Also, .bashrc is sourced by _every_ interactive shell, so if you were to add things to environment variables from .bashrc, e.g.
  PATH="$HOME/bin:$PATH"
then they would show up multiple times in shells launched inside shells. This is just an annoyance for $PATH, but it might be an important problem for other variables, so you would need to add code to test whether the variable had already been changed, etc.

This is why Ubuntu’s default .profile (see /etc/skel/.profile) sets up $PATH and the default .bashrc (see /etc/skel/.bashrc) does not.

@Derek: I don't know what's right and wrong here, but what does it really matter in practice? Have you considered the mess which would be the result if lightdm suddenly stopped to source ~/.profile?

@Myself: in my description I repeatedly used "interactive shell" when I meant "login shell" instead. The distinction is important, (and thus the shell makes the distinction)--the user's .profile is only sourced in the latter case. On all other interactive shells it sources .bashrc instead. This is so that .profile can initialize the user's terminal settings, whereas this should NOT be done for all other interactive shells.

@Anders: it need not be .bashrc, and I explicitly addressed the case where your shell was not BASH. It seems you did not read the whole report.

@Gunnar: So your argument is basically, "This is designed wrong, but we shouldn't fix it, because some people might have to learn the right way to do it." That is a pretty bad argument. The "mess" is that some percentage of users *might* need to modify their shell start-up files to do it the right way. That doesn't seem like much of a mess to me; it's fixing a mess.

It seems clear to me that .profile and the other shell start-up files belong to the shell, and hence no program other than the shell has any business reading them. Regardless, if you don't care to fix this, what's your proposed fix for lightdm barfing on errors from terminal commands that quite rightly belong in .profile? At the very least, session start-up should not be interrupted by the fact that lightdm does this badly. That behavior is a regression, in the sense that Ubuntu 12.x did not do this until some random update somewhere between six months and a year ago, and no previous Ubuntu release did it. I have not run a pristine 14.04 Ubuntu--I've only been running it for a couple of months with all current updates applied, so I can't say whether it has or has not changed there.

In the past, some distributions (including Ubuntu, if I'm not mistaken) have sourced $HOME/.profile in the system Xsession script. That solution is wrong too; but it has the nice property that if there are errors caused by the shell not running on a terminal, they are silently ignored (since there's nowhere to send them).

No, you misunderstand my comment. It doesn’t matter whether or not your shell is bash. ~/.xsession file is sourced using /bin/sh, not using your shell. You cannot expect to be able to source ~/.bashrc from ~/.xsession, no matter what your preferred shell is.

Also slight correction: BASH does NOT automatically source .bashrc on login shells; so .profile would need to source the environment file as well.

In point of fact .xsession is supposed to be an executable shell script with a shebang line, it's not supposed to be sourced at all, or at least historically that has always been the case. Theoretically the .xsession file could be a C shell script so as long as it is executed instead of sourced, this is not very interesting.

Which is a good point actually... what if the user is a C shell user? How does sourcing .profile help them? The "classic" way of setting this up is clearly far superior.

That error dialog is supposed to be helpful. ;) It was implemented (by me) as a fix of bug #678421, which was originally filed as a bug about GDM and Xsession, and one idea is to *prevent* that errors are silently ignored.

On 06/26/2015 12:58 AM, Derek Martin wrote:
> if you don't care to fix this,

I'm not in a position to decide on it.

> what's your proposed fix for lightdm barfing on errors from terminal
> commands that quite rightly belong in .profile?

Maybe state that certain commands should only be executed in case of an interactive shell. This Ask Ubuntu answer might give you a hint:

http://askubuntu.com/questions/592839

Aha, I was confusing ~/.xsessionrc with ~/.xsession. ~/.xsessionrc is sourced using /bin/sh. A default Ubuntu session does not invoke ~/.xsession at all. Creating one that works correctly with Unity or GNOME or whatever, as well as configuring LightDM to invoke it it, requires a very pointy hat.

On 06/26/2015 04:22 AM, Anders Kaseorg wrote:
> ~/.xsessionrc is sourced using /bin/sh.

Actually it's sourced using /bin/bash since a few months.

> A default Ubuntu session does not invoke
> ~/.xsession at all. Creating one that works correctly with Unity or
> GNOME or whatever, as well as configuring LightDM to invoke it it,
> requires a very pointy hat.
>

On 06/26/2015 04:22 AM, Anders Kaseorg wrote:
> ~/.xsessionrc is sourced using /bin/sh.

Actually it's sourced using /bin/bash since a few months (/bin/bash is in the shebang line of /etc/sbin/lightdm-session).

> A default Ubuntu session does not invoke ~/.xsession at all. Creating
> one that works correctly with Unity or GNOME or whatever, as well as
> configuring LightDM to invoke it it, requires a very pointy hat.

That's my understanding as well.

> The user's .profile is to be read by the shell, on interactive shell
> (i.e. terminal) logins ONLY

This is incorrect, .profile is read by the shell also when the shell is
non-interactive. Here is the quote from the bash manual:

> When Bash is invoked as an interactive login shell, or as a
> non-interactive shell with the --login option, it first reads and
> executes commands from the file /etc/profile, if that file exists.
> After reading that file, it looks for ~/.bash_profile, ~/.bash_login,
> and ~/.profile, in that order, and reads and executes commands from the
> first one that exists and is readable.

A not so far fetched example of a non interactive login shell is
something like this, where I want to source .profile but not .bashrc

$ ssh localhost "bash --login -c 'env'"

This means that .profile might be read with no tty attached, and we
should test for the presens of an attached tty when invoking stty in
.profile

.profile:
tty -s && stty erase ^H

I am interpreting a xsession as a login shell that should source .profile.