Very Computer

The man page for Bash says this:

"If bash determines it is being run by rshd, it reads and executes
commands from ~/.bashrc, if that file exists and is readable."

This seems a bit strange to me.  You usually need to set the
environment at the remote end, and considering that .bash_profile is
the place to set (and export) most environment variables (according to
one school of thought), then why doesn't it execute .bash_profile
instead?

Andrew.

Quote:>The man page for Bash says this:

>"If bash determines it is being run by rshd, it reads and executes
>commands from ~/.bashrc, if that file exists and is readable."

>This seems a bit strange to me.  You usually need to set the
>environment at the remote end, and considering that .bash_profile is
>the place to set (and export) most environment variables (according to
>one school of thought), then why doesn't it execute .bash_profile
>instead?

Because .bash_profile is only supposed to be executed by an interactive
login shell.  It's likely to contain commands that only make sense when
stdin is a terminal, not a network connection, such as stty.

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[...]

Quote:> Because .bash_profile is only supposed to be executed by an interactive
> login shell.  It's likely to contain commands that only make sense when
> stdin is a terminal, not a network connection, such as stty.

No, it's exactly the contrary. .bash_profile is read normally only once
(at login). You should define there environment variables that are
inherited by all other processes and all what is needed to setup your
whole session on that host.

.bashrc is read by every interactive shell. So you can put there
terminal initializations, alias/function definitions.

So the OP's question is totally relevant.

--
Stphane

Why would you need to reinitialize the terminal each time you started a
shell within the same login session?

.bashrc should contain things that should be executed for both interactive
and non-interactive shells.  .bash_profile should contain initializations
that are only appropriate for interactive shells, and are either
inheritable or don't need to be redone for each shell.

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[...]

Quote:> .bashrc should contain things that should be executed for both interactive
> and non-interactive shells.  .bash_profile should contain initializations
> that are only appropriate for interactive shells, and are either
> inheritable or don't need to be redone for each shell.

.bashrc is not run by non-interactive shells unless you set the BASH_ENV
variable to its path. .bash_profile is read by both interactive and
non-interactive (you don't encounter them often) login shells and
should contain initializations that are only to be made once.

See info bash at "Bash Startup Files" node.

--
Stphane

No,  Barry is correct.  .bash_profile is read at the beginning of a login
shell,  which in bash is easy to produce:

      $ cat .bash_profile
      echo bash profile entered
      $ bash --login
      bash profile entered

Quote:

> .bashrc is read by every interactive shell. So you can put there

No,  it's only read by interactive non-login shells.
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

      $ 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

      $ rsh somehost somecmd

then .bashrc and not .bash_profile will be read.

--
Dan Mercer

If responding by email, include the phrase 'from usenet'
in the subject line to avoid spam filtering.

Quote:> terminal initializations, alias/function definitions.

> So the OP's question is totally relevant.

> --
> Stphane

Opinions expressed herein are my own and may not represent those of my employer.

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.

Quote:>> .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
interactive shell.

In the bash manual, you can even see that it is advised to put a
line like:

[[ $- = *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:

PATH=$HOME/bin:$PATH

If you first log in, then start a X-Window environment, and run
a X terminal, you'll get your PATH env var as
PATH=/home/damercer/bin:/home/damercer/bin:...

Quote:> 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.

Quote:>       $ 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
remote commands.

Chet, do you read that thread?

--
Stphane

Quote:> The man page for Bash says this:

> "If bash determines it is being run by rshd, it reads and executes
> commands from ~/.bashrc, if that file exists and is readable."

Note that is is also the case when run as:

rsh somehost "bash -c '...'"

which is more a problem. I believe it's due to the fact that my
login shell "execs" bash.

And if I do

$ echo echo bashrc was sourced >> ~/.bashrc
$ echo "#! /usr/bin/ksh

Quote:> bash -c 'echo .'" > ~/a.ksh

$ chmod +x ~/a.ksh
$ rsh localhost ./a.ksh
bashrc was sourced
.

Which is not a good thing, to my mind.

Also note the:
$ env -i SSH_CLIENT= bash -c :
bashrc was sourced

--
Stphane

The original question was:

Quote:> The man page for Bash says this:

> "If bash determines it is being run by rshd, it reads and executes
> commands from ~/.bashrc, if that file exists and is readable."

> This seems a bit strange to me.  You usually need to set the
> environment at the remote end, and considering that .bash_profile is
> the place to set (and export) most environment variables (according to
> one school of thought), then why doesn't it execute .bash_profile
> instead?

> Andrew.

and the answer given was .bash_profile is for login processing when
a terminal can be presumed to exist.  Since that isn't true
for remote shell, .bashrc is used instead.  This is analogous to
csh's use of .cshrc (and probably borrowed from it).

This is a vast improvement over running remote shell with ksh
or Bourneish shells or posix shells based on Korn in which you
have to jump through hoops to set up a remote environment.

In ksh I get around the problem by running remote shell as a co-process.
I can then use any number of "print -p" commands to tailor the
remote environment before running my command.  I can also
conveniently run multiple remote commands,  all without arcane
escaping mechanisms.

--
Dan Mercer

If responding by email, include the phrase 'from usenet'
in the subject line to avoid spam filtering.

Quote:

> --
> Stphane

Opinions expressed herein are my own and may not represent those of my employer.

I suspect it assumes that when its stdin and stdout are a network socket,
it's being run by rshd.

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[...]

Quote:> and the answer given was .bash_profile is for login processing when
> a terminal can be presumed to exist.  Since that isn't true
> for remote shell, .bashrc is used instead.  This is analogous to
> csh's use of .cshrc (and probably borrowed from it).

No, csh reads .cshrc for every shell (unless the -f option is
passed). That means that a csh script reads the user's .cshrc,
csh -c some-command also reads ~/.cshrc.

Quote:> This is a vast improvement over running remote shell with ksh
> or Bourneish shells or posix shells based on Korn in which you
> have to jump through hoops to set up a remote environment.

.bashrc doesn't setup a user environment, it sets up the user
bash shell environment and I would like to say it's interactive
bash shell environment.

I don't find it is an enhancement to provide such an unexpected
behavior. For me, as stated by the rsh man page

rsh host command

should run command (command following a shell syntax) with only
the well known environment defined in the rsh man page (HOME,
PATH,...)

If one wants to set up a user environment, he should explicitely
do it:

rsh somehost '. /etc/profile
              . "$HOME"/.profile
              run some command'

Or:

rsh somehost '. "$HOME"/.bashrc
              run some command'

Which is generally not a good idea as profiles are generally
written for interactive shells.

--
Stphane

Greetings,

I have drawn up some flow charts for the startup scripts
which I keep at: http://home.sprynet.com/~ckasso/.  Is it
ok if I swipe some words from this thread to include with
the write up?  I would like to include text about the
intentions of each script and examples of what should done
in one but not the other or both ...

Thanks,
Chris Kassopulo

Quote:>.bash_profile is for login processing when
>a terminal can be presumed to exist.  Since that isn't true
>for remote shell, .bashrc is used instead.  This is analogous to
>csh's use of .cshrc (and probably borrowed from it).

>This is a vast improvement over running remote shell with ksh or
>Bourneish shells or posix shells based on Korn in which you have to
>jump through hoops to set up a remote environment.

Does this imply that most environment variables (e.g., PATH, MANPATH,
etc) should be set and exported from .bashrc?

Andrew

Good idea.

Quote:>I would like to include text about the
>intentions of each script and examples of what should done
>in one but not the other or both ...

That's the problem.  There is no common consensus on what should go
where, and in any case, it can be a hard problem to solve,
particularly when you're trying to have a consistent environment
independent of whether you login via console/terminal or xdm and then
add rsh to the equation as well.

Some people like to put everything in .bashrc and have .bash_profile
basically source .bashrc and that's it.  Others (like me) have
environment variables only set in .bash_profile.  Some people can't
stand having a PATH that grows across subshell invocations, other
people don't care.  Some people only care about specialising their
startup files so they can work in X comfortably, others only ever
login via terminal, and others need to cover the whole gamut.

Zsh seems to offer better facilities for this.  In their docs, it
basically gives a recipe, "put X here, Y there, don't put Z in W,
etc".  But Zsh also has a few extra features that make organising
startup files much easier.

Andrew.

Quote:>>.bash_profile is for login processing when
>>a terminal can be presumed to exist.  Since that isn't true
>>for remote shell, .bashrc is used instead.  This is analogous to
>>csh's use of .cshrc (and probably borrowed from it).

>>This is a vast improvement over running remote shell with ksh or
>>Bourneish shells or posix shells based on Korn in which you have to
>>jump through hoops to set up a remote environment.

>Does this imply that most environment variables (e.g., PATH, MANPATH,
>etc) should be set and exported from .bashrc?

My interactive shell is tcsh, and I set all my environment variables in
.cshrc.

This means that when I assign to these variables I have to provide the
complete setting, not just append/prepend to them, so that it doesn't grow
longer in each nested shell.

--

Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.