Alternatively reproduced here without the '>': http://blog.flowblok.id.au/2013-02/shell-startup-scripts.htm...
Edit: Not that I recommend the resource, just fixed the link for you.
In ubuntu that's stuff like the load average of the machine or whether or not there are packages that need to be upgraded.
I don't understand this. If I set PATH in .profile or .bash_profile, then on Ubuntu I won't see that setting when I log in via a non-login shell. This is common for non-interactive SSH sessions.
So consider the following example:
* I install MPI to /usr/local/openmpi-X.Y.Z
* I add /usr/local/openmpi-X.Y.Z/bin to PATH, inside my .profile
I think I'll keep my PATH settings in .bashrc, thank you very much.
Thanks for bringing this up.
Sure, you could source .profile manually, but this is awkward to code inside an MPI application. In addition, this will cause .bashrc to get sourced twice, because your shell already read .bashrc when it started the SSH session. Hopefully your .bashrc is idempotent, but even so, it feels wrong to have to read .bashrc twice.
Try this on a remote server:
remote:~$ cat .profile
echo "read .profile"
echo "sourcing .bashrc from .profile"
source ~/.bashrc
remote:~$ cat .bashrc
echo "read .bashrc"
local:~$ ssh remote
read .profile
sourcing .bashrc from .profile
read .bashrc
local:~$ ssh remote -k true
read .bashrcI recently had the task of straightening out the default install of dotfiles we had at my job. Since we're behind a corporate firewall and require various HTTP proxies to hit the outside world I devised pretty much the same setup as explained in the article.
All of the environment exports are placed in .profile as, at the very least, I expect this to be sourced on a login shell. If there is a non-login shell, for the most part, most people tend to source it pretty early on in the process. The .bash_profile is kept around for diagnostic information for interactive shells such as the Ruby, Go, Node and Java versions of the machine you are logging into.
Because everyone tends to have their own dotfiles I hijacked the .bash_login to keep machine specific information which can be optionally sourced. This leads me to tell people to basically keep .profile and .bash_login out of their revision control and to source both of them relatively early on in the login process.
All .profile is for environment variables that are machine/network specific. If you have any overrides, e.g. aliases, all that goes into your .bash_login.
My .bash_profile: https://github.com/johnbellone/dotfiles/blob/master/home/.ba...
My .bashrc https://github.com/johnbellone/dotfiles/blob/master/home/.ba...
You can also rename .profile to .bash_profile on Ubuntu and Debian. All other distros that I've encountered set up .bash_profile by default.
What I don’t get is why RVM adds a .bash_profile, when there is, for example, /etc/profile.d/.
> the scary console login after you've messed up your GUI settings
BASH isn't that mysterious.
man bash"help" is the most likely first place looked for assistance in such circumstances I'd imagine.
I think booting to a console when you expect a desktop can be scary, especially if you don't know how to undo whatever you did.