Re: why ~/.bashrc in ssh or scp??

[Chet Ramey]

Stephane Chazelas wrote:
> I find bash policy about startup files a bit confusing. I've
> never quite understood why login shells wouldn't read the
> ~/.bashrc file (I would have considered this file as in other
> shells or even other programs as the customization file, so why
> not applying customizations to the login shells?).

I don't want to speak for Brian, since this behavior was in bash
before I got involved with it, but I have always assumed that it
was a compromise between the traditional sh and csh behaviors.

You can make bash behave just like sh:  .profile and no .bashrc,
or like csh:  .bash_profile which sources .bashrc and .bashrc.

> I've just discovered that the shells run with -c 'command line'
> within a ssh or rsh non-interactive session were reading the
> ~/.bashrc. This left me very perplex.
>
> Someone suggested that it might be so that:
>
> in
>
> local-shell$ ssh some-host
> remote-shell$ some shell command line
> remote-shell$ exit
> local-shell$
>
> and in
>
> ssh some-host 'some shell command line'
>
> The "some shell command line" is interpreted the same way.

Pretty much.  It's a way for people to use the same $PATH on the
remote host they get when starting an interactive shell session.
It was originally intended for use with rsh, and extended to
ssh (through several iterations) when folks complained that ssh's
.environment file wasn't up to the job.

> And shouldn't it be limited to the bash instances run by sshd or
> rshd and not every bash instance started during the session?

Sure, in a perfect world.  Unfortunately, the heuristics used to
decide whether or not a command is run by rshd (-c command,
stdin is a socket, $SHLVL < 2) can be fooled.

> Also, why should the behavior be different in "rsh" and in "rsh
> -n"?

Because one of the heuristics is that stdin be a socket.  With
`rsh -n', stdin is closed.

Chet