Timeline for Difference between .bashrc and .bash_profile
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 5, 2022 at 23:28 | comment | added | SpinUp __ A Davis |
@zyy csh and tcsh have their own set of startup files (e.g. /etc/csh.cshrc), so they won't read ~/.profile
|
|
| Nov 13, 2021 at 13:02 | comment | added | zyy |
Seems like it would be hard to make ~/.profile compatible with csh and bash at the same time, because csh uses setenv while bash uses export.
|
|
| Nov 9, 2021 at 9:03 | comment | added | Gilles 'SO- stop being evil' |
@BeeOnRope It depends on the distribution and on the desktop environment. Many arrange to source .profile from the X session startup script, some even source .bash_profile (but not many, since this requires running those scripts with bash and not dash). But unfortunately there's no de facto standard like there is for non-GUI login.
|
|
| Nov 8, 2021 at 23:59 | comment | added | BeeOnRope |
The situation with GUI shells .profile and .bash_profile isn't clear from this answer (or the others). in a typical Linux desktop environment which launches into a graphical window manager, and then where the user launches a non-login shell via a terminal emulator, is .[bash_]profile ever executed? It would seem not since you never type your password at a shell. However, this would make .[bash_]profile unsuitable for the purpose suggested in the answer since it usually doesn't execute. Or does the window manager count as a "shell" and execute .profile or .bash_profile?
|
|
| Sep 23, 2020 at 12:49 | review | Suggested edits | |||
| Sep 23, 2020 at 17:39 | |||||
| Sep 20, 2020 at 19:29 | comment | added | Gilles 'SO- stop being evil' | @Joachim I mean programs with a graphical user interface. This has nothing to do with what language(s) they're written in. | |
| Sep 20, 2020 at 19:14 | comment | added | Joachim | What do you mean exactly by "graphical program" ? Do you mean like a python or c++ executables ? | |
| Feb 21, 2019 at 20:23 | comment | added | Jesse Chisholm |
re: Bash is a Bourne-like shell. Speaking as one who was using sh before there was a bash, it was originally referred to as the Bourne again shell.
|
|
| Jun 7, 2018 at 22:56 | comment | added | jamesdlin | "The most common problem with either of these ideas..." But that sounds like a problem in general (as you say, there is no standard location for graphical environments to read environment variables from). Even if the graphical environment documents a location, will that location be read when logging in via, say, ssh? It seems to me that there are problems with every approach, so people need to pick their poison. | |
| Mar 21, 2018 at 21:29 | comment | added | Gilles 'SO- stop being evil' | @Tim I have already answered this many times on Unix & Linux. Please learn to search. | |
| Mar 21, 2018 at 20:40 | comment | added | Tim |
Thanks, Gilles. Why define environment variables in ~/.profile or ~/.bash_profile, and alias and functions in ~/.bashrc?
|
|
| Mar 25, 2017 at 0:04 | comment | added | Gilles 'SO- stop being evil' | @Abdul Yes, see the second paragraph of my answer. | |
| Mar 24, 2017 at 11:32 | comment | added | Honinbo Shusaku |
Just for clarification, "If the shell is not a login shell, it doesn't read ~/.profile" -> Does ~/.profile in this sentence also include ~/.bash_profile?
|
|
| Dec 9, 2016 at 21:35 | comment | added | Sean McSomething | Just spent the last hour figuring out how it works in Cygwin. Cygwin, like Terminal, gives you a new login shell for each window. | |
| Mar 6, 2014 at 10:07 | comment | added | Gilles 'SO- stop being evil' |
@PiotrDobrogost Ok, but .bash_login is just an alternate name for .bash_profile that hardly anybody uses.
|
|
| Mar 6, 2014 at 10:07 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 3.0 |
mention .bash_login by request; don't imply that having .profile dispenses from the need to read .bashrc in a login instance of bash
|
| Mar 6, 2014 at 9:56 | comment | added | Piotr Dobrogost |
Would you please update your answer with information on .bash_login? This could also be a chance to take into account my previous comments if you wish.
|
|
| Jan 19, 2014 at 0:30 | comment | added | Billy McCloskey |
It is a simple task to change the OSX Terminal to be an interactive NON-login shell like some other UNIX distributions. Simply edit the OSX Terminal preferences and change the Shells open with: to the command /usr/bin/login -f -l userid bash -i. This will change the convention to kick off all Terminal as interactive NON-login shells. Keep in mind, that if this is done, the $HOME/.profile will stop being sourced for one. A major overhaul of startup sequence calls would ensue.
|
|
| Jun 15, 2013 at 12:29 | comment | added | Piotr Dobrogost |
@Gilles Sure, but the way the sentence is formulated in the answer suggests that the need to include ~/.bashrc has something to do with choosing ~/.bash_profile instead of ~/.profile which is not true. If someone includes ~/.bashrc in any kind of script being sourced at login time (here it's either ~/.bash_profile or ~/.profile) is because he wants settings from ~/.bashrc to be applied to the login shell the same way they are being applied to non-login shell.
|
|
| Jun 15, 2013 at 11:20 | comment | added | Gilles 'SO- stop being evil' |
@PiotrDobrogost .bash_profile is only read by bash. If you don't have that file, then bash reads .profile instead. If you have only a .profile, then it must include .bashrc, but only if the shell is interactive and is bash, not if the login shell is some other shell.
|
|
| Jun 15, 2013 at 11:20 | comment | added | Piotr Dobrogost |
The statement ~/.bash_profile can be used instead of ~/.profile, but you also need to include ~/.bashrc if the shell is interactive. is misleading as these are orthogonal issues. No matter if you use ~/.bash_profile or ~/.profile you have to include ~/.bashrc in the one you use if you want settings from there to have effect in the login shell.
|
|
| Jun 12, 2012 at 17:57 | comment | added | Gilles 'SO- stop being evil' | @Brandon If you run a login shell in every terminal, that will override environment variables provided by the environment. In everyday situations, you can get away with it, but it'll come and bite you sooner or later, when you want to set up different variables in a terminal (say, to try out a different version of a program): running a login shell would override your local settings. | |
| Jun 12, 2012 at 16:38 | comment | added | iconoclast | @Gilles: Could you explain in more detail, with examples, of why running a login shell in every terminal is a bad idea? Is this only an issue with desktop Linux? (I gather that on OS X Terminal runs a login shell every time, and I've never noticed any side effects (though I usually use iTerm). But then I can't think of many environment variables I'd care about outside of a terminal. (Maybe HTTP_PROXY?)) | |
| Sep 17, 2011 at 21:41 | comment | added | Trevor Boyd Smith | +1 for good post. ALSO thank you for adding section about "login graphical vs login shell"... I had the problem where I thought ~/.profile would ALWAYS execute for graphical/shell... but it doesn't execute for when the user logs in via graphical login. Thank you for solving that mystery. | |
| Sep 3, 2010 at 13:48 | vote | accept | cfischer | ||
| Sep 2, 2010 at 19:23 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 2.5 |