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