Timeline for Difference between .bashrc and .bash_profile
Current License: CC BY-SA 2.5
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 14, 2021 at 22:56 | comment | added | michael |
No, running ssh hostname {command} is not interactive; the connection is closed after the command exits (eg ssh [email protected] ps) and there's no terminal set & any initialization that expects a terminal will fail & break the ssh command and prevent it from executing.
|
|
| Jun 14, 2021 at 10:34 | comment | added | Dr Krishnakumar Gopalakrishnan |
@michael ssh shells are interactive, right? So, ~/.bashrc will run on it. The GNU bash manual explicitly states this.
|
|
| Jun 14, 2021 at 10:16 | comment | added | Dr Krishnakumar Gopalakrishnan |
.bashrc is sourced for all shells, interactive and non-interactive. I don't think that is true. ~/.bashrc is sourced only for non-interactive shells.
|
|
| May 20, 2021 at 16:01 | comment | added | phzx_munki |
In stock, brand new installations of RHEL8 and Ubuntu 21.04, the user's .bash_profile contains these lines: if [ -f ~/.bashrc ]; then . ~/.bashrc ; fi And the .bashrc contains: PATH="$HOME/.local/bin:$HOME/bin:$PATH" ; export PATH So, I would say Rich Homolka is correct. Follow the vendor defaults, and dot your .bashrc in your .profile or .bash_profile. Or just put everything in .bashrc and make the .bash_profile contain only the line Rich suggests.
|
|
| Nov 1, 2020 at 17:13 | review | Suggested edits | |||
| Nov 5, 2020 at 5:56 | |||||
| Jul 29, 2013 at 6:30 | comment | added | michael |
In general, +1, but I would add to the recommendation to "short circuit...for non-interactive shells" ("near the top of .bashrc: [[ $- != *i* ]] && return"); I do like some of my .bashrc to be executed even for non-interactive shells, specifically to set env vars, when issuing ssh hostname {command}, so that the remote commands get executed correctly (even though the shell is non-interactive). But other settings later in .bashrc should be ignored. I usually check for TERM=dumb and/or unset, and then bail out early.
|
|
| Jul 29, 2013 at 6:17 | comment | added | michael | @Gilles re: "including .bashrc in .profile" is not at all what was recommended (quite the contrary, in fact). Either the answer was edited (it doesn't appear so), or your comments don't align with what is being said. | |
| Jun 15, 2013 at 11:24 | comment | added | Gilles 'SO- stop being evil' |
@PiotrDobrogost Oh, yes, there's another problem with Rich's answer. Including .bashrc in .profile typically doesn't work, because .profile may be executed by /bin/sh and not bash (e.g. on Ubuntu for a graphical login by default), and that shell may not be interactive (e.g. for a graphical login).
|
|
| Jun 2, 2012 at 16:25 | comment | added | Mikel |
@Gilles I don't understand why you claim this. With .$HOME/.bashrc as Rich showed above, settings in .bashrc will be available in login shells, and thus the desktop environment as well. For example, on my Fedora system, gnome-session is started as -$SHELL -c gnome-session, so .profile is read.
|
|
| Sep 2, 2010 at 19:24 | comment | added | Gilles 'SO- stop being evil' | This is a bad idea, see my answer. In particular, your environment variables will only be set in programs launched via the terminal, not in programs started directly with an icon or menu or keyboard shortcut. | |
| Sep 2, 2010 at 18:10 | history | answered | Rich Homolka | CC BY-SA 2.5 |