Quote:> No, Barry is correct. .bash_profile is read at the beginning of a login
> shell, which in bash is easy to produce:
This is what I said.
>> .bashrc is read by every interactive shell. So you can put there
> No, it's only read by interactive non-login shells.
Yes, you're right about this. That was not my point. My point
was that .bashrc was the place to put definitions for an
In the bash manual, you can even see that it is advised to put a
[[ $- = *i* && -r ~/.bashrc ]] && . ~/.bashrc
in the ~/.bash_profile (more or less ;)
Quote:> It is not uncommon to link .bash_profile and .bashrc if you do nothing
> different between interactive shells whether they are login or not,
> or at least to source one from the other.
If you link .bashrc to .bash_profile, for instance if you have
in your ~/.bash_profile:
If you first log in, then start a X-Window environment, and run
a X terminal, you'll get your PATH env var as
> If you
> $ rsh somehost
> then you will get a login shell just as if you rloginned and
> .bash_profile and not .bashrc will be read. If you
That's exactly the point
rsh somehost is a shortcut for rlogin somehost but it is
something totally different. It doesn't use the same tcp port
nor the same protocol nor the same daemon.
On my Linux system:
$ strace -e trace=execve rsh localhost
execve("/usr/bin/rsh", ["rsh", "localhost"], [/* 46 vars */]) = 0
execve("/usr/bin/rlogin", ["rlogin", "localhost"], [/* 46 vars */]) = 0
i.e. rsh execs rlogin when there's no specific command to run.
> $ rsh somehost somecmd
> then .bashrc and not .bash_profile will be read.
But your arguments don't justify this. I guess the first intent
was to make the aliases, functions... etc defined in the .bashrc
(the file to be read for *interactive* shells) available for
Chet, do you read that thread?