[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: why ~/.bashrc in ssh or scp??
Date: Mon, 17 Jan 2005 15:01:54 -0500
User-agent: Mozilla Thunderbird 0.9 (Windows/20041103)

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:


local-shell$ ssh some-host
remote-shell$ some shell command line
remote-shell$ exit

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]