Justin wrote:
I am using a command line ssh tool called qtssh on windows to
connect to a redhat server. qtssh is a command line ssh tool built
upon putty that is included with the visualization toolkit VisIt.
This tool is designed to run commands remotely and does not create
an interactive shell.
You describe an environment that is designed to run scripts only.
Okay. Seems reasonable to me.
When connecting to the redhat server none of my startup scripts
appear to be executed (.bashrc, .bash_profile, .profile, etc).
Not for a non-interactive environment.
However, if I connect to my Debian server the .bashrc file is
sourced just fine.
Please see /usr/share/doc/bash/README.Debian.gz for a description of
Debian specific modifications.
- try to check whether bash is being run by sshd and source
the .bashrc if so (like the rshd behavior).
Because this is a Debian specific patch it won't exist elsewhere.
From what I can tell ssh is starting a non-interactive and non-login
shell. The documentation on what is executed when this type of
shell is encountered says: 'When bash is started non-interactively,
to run a shell script, for example, it looks for the variable
BASH_ENV in the environment, expands its value if it appears there,
and uses the expanded value as the name of a file to read and
execute.' This variable is not set on any of the machines i'm on
and it is not clear how to appropriately set this variable.
In traditional ksh there isn't a default $HOME/.kshrc file sourced by
the shell for interacive login shells. In order to enable this
csh-like feature one needed to set ENV=$HOME/.kshrc (or other name).
However that had the unfortunate effect that scripts also sourced that
same file. Aliases and functions meant for interactive use could
break scripts not expecting non-standard behavior. Therefore
typically a somewhat complicated computation such that interactive
shells would source the .kshrc while non-interactive shells would not
source this file. This was needed for ksh scripts to operate robustly.
export ENV='${START[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'
export START=$HOME//.kshrc
Or from the KornShell book. Requires ksh88 or later.
export ENV='${FILE[(_$-=0)+(_=1)-_${-%%*I*}]}'
export FILE=$HOME//.kshrc
Bash avoided these issues by implementing a different set of startup
rules that automatically did the right thing in more cases. Bash
supports the functionality of the ksh ENV by using a BASH_ENV variable
with similar behavior. Bash also supports ENV when invoked as 'sh'
and so forth as documented in the manual for legacy support.
Even though bash works as desired most of the time there is still
debate as to what behavior is desired in the subtle differences
between an interactive shell and a non-interactive shell and in a
login shell versus a non-login shell and when being run over a remote
shell connection (e.g. using ssh or rsh) versus not. Automatically
trying to dynamically choose behavior invariably fails to work in all
cases and causes problems in those failing cases. This has led to a
rather complex set of rules for shell startup and the files it
sources. This is the problem you are looking at right now.
My personal opinion is that flexibility is good, if confusing, and I
would rather have it than not. But keep the rules constant! When the
rules have changed in the past from one behavior to another it has
caused me grief. It creates "versionitis" problems trying to adapt to
which shell does what behavior in which version.
There has been various extended mailing list discussions about the
best behavior when being run on a remote shell such as over ssh and
rsh. Search the archives for a full history. Some want it and some
don't want it.
Am I correct in assuming that this variable needs to be set in order
to get the dot files sourced and if so where is this variable set?
Well, yes and no. If it is set, such as in a user's .profile then
bash will source the indicated file. However IMNHO this is only
desirable to directly support this ksh-like behavior. Most of the
time you don't want to do things this way. For one it slows down
scripts that now need to source this extra file. For another code
there can break random scripts not expecting non-standard behavior.
In my opinion you don't want to do it this way. Trying to set the
BASH_ENV on a remote command so that the .bashrc on the remote system
is sourced just doesn't feel like the right way to go about things.
Instead I would probably execute a script on the remote host and in
that script I would do whatever task I wanted done on the remote
machine and it would operate in a standard environment. But you
didn't give an example of what you were wanting so I can't guess if
you were trying to set PATH or desiring an alias or function to exist
or what. So I realize that this answer will be unsatisfying in that
regard.
Hope this helps,
Bob