Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am using an AIX 5.3 server with a .bashrc file set up to echo "Executing bashrc." When I log in to the server using ssh and run:

bash -c ls

I get:

Executing bashrc
.
..
etc....

However, when I log in with telnet as the same user and run the same command I get:

.
..
etc....

Clearly in the telnet case, the .bashrc was not invoked. As near as I can tell this is the correct behaviour given that the shell is non-interactive in both cases (it is invoked with -c). However, the ssh case seems to be invoking the shell as interactive. It does not appear to be invoking the .profile, so it is not creating a login shell. I cannot see anything obviously different between the environments in the two cases.

What could be causing the difference in bash behaviour?

share|improve this question

3 Answers 3

Check to make sure that the login shell you're in doesn't have an alias or a different PATH depending on whether you're logged in via ssh or telnet. Compare this each way:

type -a bash

There could be some conditional code in one of:

  • /etc/profile
  • /.bash_profile
  • ~/.bash_login
  • ~/.profile
  • ~/.bashrc

That sets the PATH differently or creates an alias depending on whether you're logged in via ssh or telnet. The PATH could point to different versions of Bash that are compiled with different options. An alias could be something like alias bash='bash -i'.

If you echo $SHELL as Nikolaidis suggests, that's only going to show what's set in /etc/passwd as your login shell. It might be more reliable to use ps. If for some reason you're getting a shell other than Bash, you'll need to check its startup files and environment to see if the PATH or aliases are different. Generally, though, your interactive shell shouldn't affect how explicitly calling bash -c works.

And you're correct about this:

As near as I can tell this is the correct behaviour given that the shell is non-interactive in both cases (it is invoked with -c).

share|improve this answer
    
PATH is the same in both cases (we set it explicitly). type -a bash lists only /usr/bin/bash in both cases. SHELL is set to /bin/bash. Otherwise the environments are exactly the same except for a couple of ssh-specific variables (SSH_CONNECTION, SSH_CLIENT, SSH_TTY). Explicitly running /usr/bin/bash or /bin/bash (with full path) yields the same results I listed above. Running bash --norc -c ls prevents ~/.bashrc from being sourced, but that doesn't answer the question of where the difference is coming from. –  Philbert Aug 19 '10 at 14:49
    
@Philbert: The next thing I would suggest is to turn on tracing and see if that shows any difference: bash -cx pwd (I use pwd since the output is only one line). –  Dennis Williamson Aug 19 '10 at 16:49
    
Sorry for the late reply. The only difference is the + ~/.bashrc and its subsequent code. –  Philbert Aug 24 '10 at 14:42

From the Bash man page, this is "normal" behaviour - bash attempts to decide if you're running it from sshd first:

Invoked by remote shell daemon

Bash attempts to determine when it is being run with its standard input connected to a a network connection, as if by the remote shell daemon, usually rshd, or the secure shell daemon sshd. If Bash determines it is being run in this fashion, it reads and executes commands from ~/.bashrc, if that file exists and is readable. It will not do this if invoked as sh. The --norc option may be used to inhibit this behavior, and the --rcfile option may be used to force another file to be read, but rshd does not generally invoke the shell with those options or allow them to be specified.

share|improve this answer

try echo $SHELL in both cases. this is to see it bash in actually the shell in both cases.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.