.bashrc not being sourced

Hi,

I’m running a very simple ansible command:

ansible staging -m shell -a ‘echo $PATH’ -c ssh

I expect this command to return the same $PATH that’s printed when I run ‘echo $PATH’ when logging directly using SSH, however, this does not happen. The path I’m getting from ansible is that one set in /etc/environment and not the one set in .bashrc (which, to my best understanding should have been sourced)

I feel that I’m missing something pretty basic here.

Thanks,
Shahar

When bash is invoked as an interactive login shell, or as a non-interac-
        tive shell with the --login option, it first reads and executes commands
        from the file /etc/profile, if that file exists. After reading that file,
        it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that
        order, and reads and executes commands from the first one that exists and
        is readable. The --noprofile option may be used when the shell is started
        to inhibit this behavior.

        When a login shell exits, bash reads and executes commands from the files
        ~/.bash_logout and /etc/bash.bash_logout, if the files exists.

        When an interactive shell that is not a login shell is started, bash reads
        and executes commands from ~/.bashrc, if that file exists. This may be
        inhibited by using the --norc option. The --rcfile file option will force
        bash to read and execute commands from file instead of ~/.bashrc.

        When bash is started non-interactively, to run a shell script, for exam-
        ple, 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. Bash behaves as if the following command were
        executed:
               if [ -n "$BASH_ENV" ]; then . "$BASH_ENV"; fi
        but the value of the PATH variable is not used to search for the file
        name.

        If bash is invoked with the name sh, it tries to mimic the startup behav-
        ior of historical versions of sh as closely as possible, while conforming
        to the POSIX standard as well. When invoked as an interactive login
        shell, or a non-interactive shell with the --login option, it first
        attempts to read and execute commands from /etc/profile and ~/.profile, in
        that order. The --noprofile option may be used to inhibit this behavior.
        When invoked as an interactive shell with the name sh, bash looks for the
        variable ENV, expands its value if it is defined, and uses the expanded
        value as the name of a file to read and execute. Since a shell invoked as
        sh does not attempt to read and execute commands from any other startup
        files, the --rcfile option has no effect. A non-interactive shell invoked
        with the name sh does not attempt to read any other startup files. When
        invoked as sh, bash enters posix mode after the startup files are read.

And I think this last paragraph is the most relevant here. Bash is in fact being invoked as /bin/sh and .bashrc is meant for very specific bash stuff. PATH is not something you would set for only bash, so it does not belong in .bashrc.

And to prove my point:

     [dag@moria ~]$ strace -f -e open /bin/sh
     open("/etc/ld.so.cache", O_RDONLY) = 3
     open("/lib64/libtinfo.so.5", O_RDONLY) = 3
     open("/lib64/libdl.so.2", O_RDONLY) = 3
     open("/lib64/libc.so.6", O_RDONLY) = 3
     open("/dev/tty", O_RDWR|O_NONBLOCK) = 3
     open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
     open("/proc/meminfo", O_RDONLY) = 3
     open("/etc/nsswitch.conf", O_RDONLY) = 3
     open("/etc/ld.so.cache", O_RDONLY) = 3
     open("/lib64/libnss_files.so.2", O_RDONLY) = 3
     open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
     open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3
     open("/home/dag/.bash_history", O_RDONLY) = 3
     open("/usr/share/terminfo/x/xterm", O_RDONLY) = 3
     open("/home/dag/.inputrc", O_RDONLY) = 3

Try the same thing with /bin/bash and you'll see the difference.

What you can do though is invoke it like:

     ansible staging -m shell -a 'echo $PATH executable=/bin/bash' -c ssh

But in my opinion your PATH should not go into .bashrc or .bash_profile !

Hi Dag,

I appreciate the answer. Adding executable=/bin/bash did not do the trick. What finally worked for me was sourcing the required shell file myself as follows:

ansible staging -m shell -a ‘[[ -s “$HOME/.rvm/scripts/rvm” ]] && source “$HOME/.rvm/scripts/rvm” executable=/bin/bash’

Not the most elegant way to do things…

I could change the path set in /etc/environment, but I’m not sure that would be the right thing to do. Why should all users, logging into the server, have Ruby in their PATH? That doesn’t seem right either.

Where would you suggest setting the PATH so it’s isolated to a specific user and yet accessible from within any shell session?

Thanks,
Shahar

What is your remote machine OS, Ubuntu/Debian ?

If its Ubuntu you need to change defaults.

Here is my playbook snippet.


   - name: Comment out line which prevents loading bash profile by ssh

     lineinfile: dest=~/.bashrc regexp='[ -z "$PS1" ] && return' line='# [ -z "$PS1" ] && return' state=present

     when_string: $ansible_pkg_mgr == 'apt'

Regards,

See what dag posted about .bashrc vs .bash_profile