General Computing
linux bash ssh terminal shell
Updated Fri, 20 May 2022 01:15:14 GMT

Why does my .bashrc get read when I run noninteractive commands over ssh


I've prepended each of my bash config files (~/.bashrc,~/.bash_profile,~/.profile) with echo NAME_OF_FILE, i.e. I get '.bashrc' when I source in ~/.bashrc.

What baffles me is why I get and indication that ~/.bashrc gets included when I run a command over ssh. E.g., if I do:

ssh localhost echo hi

I get 

.bashrc
hi

Why is getting ~/.bashrc sourced in in this context? Shouldn't it NOT get sourced in since this should run an non-interactive bash session?

Indeed, ssh localhost tty gets me a 'not a tty' (preceded by '.bashrc' indicating that ~/.bashrc gets sourced in nonetheless).

I've grepped all my config files for commands sourcing in ~/.bashrc explicitly, and there are none that explain it.

(I only have tty -s && shopt -q login_shell && [[ -r ~/.bashrc ]] && . ~/.bashrc in my .bash_profile so that I get '.bashrc' even in interactive login shells, but this doesn't explain the ssh issueI can comment it out and I still get the same behavior with the above ssh examples)

How can I debug this?

Solution

From bash man page:

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.

I.e. ~/.bashrc will get run when you invoke it via ssh, regardless of whether you have a tty or not.

If you only want your .bashrc to run when you are interactive, try this at the top:

# If not running interactively, don't do anything
[[ "$-" != *i* ]] && return

If that doesn't work, try this:

[ -z "$PS1" ] && return




Comments (5)

  • +1 – The manual page is a bit unclear, as most remote connection tools rshd, telnetd, sshd attach bash's stdin/stdout to a pseudoterminal, not directly to the network socket (which would actually be impossible for sshd). Will check the source code later. — May 07, 2014 at 14:11  
  • +0 – Both didn't work on CentOS 7. — May 02, 2018 at 14:19  
  • +0 – @yildizabdullah you need to debug. Start by adding an echo or set -x at the top and see if your .bashrc is even being called. Then examine the values of those variables. — May 03, 2018 at 08:13  
  • +0 – @Lqueryvg I added echo command at the top and it ran. That is, .bashrc was called. — May 03, 2018 at 09:27  
  • +0 – Do a set and an env - try to work out what $- and $PS1 are set to. (I'm starting to wonder if you are really in bash.). Type bash to get a sub-shell - so that you definitely know you are in a bash - and look at the values there. — May 03, 2018 at 09:55  

References