The way it's supposed work is that, at the point when you get a shell prompt, both .profile
and .bashrc
have been run. The specific details of how you get to that point are of secondary relevance, but if either of the files didn't get run at all, you'd have a shell with incomplete settings.
The reason terminal emulators on Linux (and other X-based systems) don't need to run .profile
themselves is that it will normally have been run already when you logged in to X. The settings in .profile
are supposed to be of the kind that can be inherited by subprocesses, so as long as it's executed once when you log in (e.g. via .Xsession
), any further subshells don't need to re-run it.
As the Debian wiki page linked by Alan Shutko explains:
"Why is .bashrc
a separate file from .bash_profile
, then? This is done for mostly historical reasons, when machines were extremely slow compared to today's workstations. Processing the commands in .profile
or .bash_profile
could take quite a long time, especially on a machine where a lot of the work had to be done by external commands (pre-bash). So the difficult initial set-up commands, which create environment variables that can be passed down to child processes, are put in .bash_profile
. The transient settings and aliases which are not inherited are put in .bashrc
so that they can be re-read by every subshell."
All the same rules hold on OSX, too, except for one thing — the OSX GUI doesn't run .profile
when you log in, apparently because it has its own method of loading global settings. But that means that a terminal emulator on OSX does need to run .profile
(by telling the shell it launches that it's a login shell), otherwise you'd end up with a potentially crippled shell.
Now, a kind of a silly peculiarity of bash, not shared by most other shells, is that it will not automatically run .bashrc
if it's started as a login shell. The standard work-around for that is to include something like the following commands in .bash_profile
:
[[ -e ~/.profile ]] && source ~/.profile # load generic profile settings
[[ -e ~/.bashrc ]] && source ~/.bashrc # load aliases etc.
Alternatively, it's possible to have no .bash_profile
at all, and just include some bash-specific code in the generic .profile
file to run .bashrc
if needed.
If the OSX default .bash_profile
or .profile
doesn't do this, then that's arguably a bug. In any case, the proper work-around is to simply add those lines to .bash_profile
.
Edit: As strugee notes, the default shell on OSX used to be tcsh, whose behavior is much saner in this respect: when run as an interactive login shell, tcsh automatically reads both .profile
and .tcshrc
/ .cshrc
, and thus does not need any workarounds like the .bash_profile
trick shown above.
Based on this, I'm 99% sure that the failure of OSX to supply an appropriate default .bash_profile
is because, when they switched from tcsh to bash, the folks at Apple simply didn't notice this little wart in bash's startup behavior. With tcsh, no such tricks were needed — starting tcsh as a login shell from an OSX terminal emulator Just Plain Works and does the right thing without such kluges.
Best Answer
The original UNIX versions 5-7 can be seen doing the same thing. (
UFD output = 2;
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/main.c)time
is/was a builtin, and it's definitely useful that it outputs to stderr. Howevertime
is not one of the builtins in V5.I don't think there were any big reasons not to write terminal output to stderr. Output from the shell was either clearly an error message, or output intended for interactive terminals only. It was not necessary for redirecting stdout to redirect the interactive output.
Although stderr was introduced in V6, not V5, in V5
sh
manuallydup()
s stdout to FD 2 after closing the old FD 2 if necessary. It seems they already found a need to print error messages e.g. ifexec()
failed when trying to launch a command likefoo > output
.Now pay attention to how compact the historical unix code is. It is deliberately kept short, because there wasn't necessarily very much physical RAM.
There is a single
prs()
function to print strings. It does not take an FD parameter. It prints error messages to FD 2, and the other strings are also OK to print to FD 2, so it simply prints to FD 2 unconditionally. Short code, that compiles to few instructions, hence using minimal RAM.And once things are around for a while, changing them always has the risk of breaking more things than it improves.
What puzzles me is why the developers of python even noticed this and copied it - IMO it's a pretty obscure fact. Maybe it implies an additional reason that I haven't found.