The Bash manpage says:
After reading that file (/etc/profile), 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.
So if I have both a ~/.bash_profile and a ~/.profile, only the first will be run.
Because I often share a HOME between different systems I have both, hard linked. On 18.04.2 a login returns to the login screen. With each as a separate but identical file, the same happens. To share between systems and available shells my .profile contains a case statement based on $0, setting up as appropriate or executing a preferred shell. Effectively it does:
case $0 in
*bash) ... some stuff ...
;;
*) exec /bin/bash -il
;;
esacPutting a # before the exec in the .profile copy and all works well...
The .bash_profile is identical (apart from the # in .profile when I insert one).
It turns out that 18.04.2 is quite happy with that exec in ~/.bash_profile, but not in ~/.profile (which it shouldn't be reading anyway). When it's there, logging in takes the password → black screen briefly → login window again. When it's commented out, login happens properly. Also the shell is Bash, so that branch of the case shouldn't be being taken either.
Thoughts?
21 Answer
The GUI login process may source /etc/profile and ~/.profile for setting up environment variables, etc., and it may use /bin/dash or /bin/bash for that. Ask Ubuntu has many instances of GUI login failing because of errors in ~/.profile or /etc/profile. You shouldn't be exec'ing something else in these files without checking for interactive usage at the very least. For example, the default .bashrc has this at the top, which you could adapt:
~ head /etc/skel/.bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
case $- in *i*) ;; *) return;;
esac 2