11–20 of 22 posts
What's the reason for all the files, and why do I care whether my shell is a login or non-login? To me, no matter where I get my shell from (whether VT, SSH, gnome-terminal), I want all my aliases, settings and nice terminal colors to be there.
Is there a specific reason why you would want to source .profile from within .bash_profile instead of just making one a symlink to the other?
Programs like RVM add a .bash_profile file so you should be sure to append [[ -s ${HOME}/.profile ]] && source ${HOME}/.profile to the added .bash_profile file. 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 bashPrograms like RVM add a .bash_profile file so you should be sure to append [[ -s ${HOME}/.profile ]] && source ${HOME}/.profile to the added .bash_profile file. 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.
> the scary console login after you've messed up your GUI settings That's where I stopped reading... BASH isn't that mysterious. man bash
"help" is the most likely first place looked for assistance in such circumstances I'd imagine.
I 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...
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.
> As the name implies, .bashrc is for bash configs. Environment variables or other configuration settings should typically be written to .profile on Ubuntu and .bash_profile on OS X. 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 ins…
Thanks for bringing this up.