.bashrc not being sourced

4,619 views
Skip to first unread message

Shahar Kedar

unread,
Jun 26, 2013, 3:30:38 PM6/26/13
to ansible...@googlegroups.com
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

Dag Wieers

unread,
Jun 26, 2013, 4:34:16 PM6/26/13
to ansible...@googlegroups.com
From 'man bash' it reads:

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("/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 !

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, con...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

Shahar Kedar

unread,
Jun 26, 2013, 5:02:47 PM6/26/13
to ansible...@googlegroups.com
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





--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/dYULdNhL8cs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-project+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



Kavin Kankeshwar

unread,
Jun 26, 2013, 5:06:22 PM6/26/13
to ansible...@googlegroups.com
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,
--
Kavin.Kankeshwar



--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.

Michael DeHaan

unread,
Jun 26, 2013, 5:33:44 PM6/26/13
to ansible...@googlegroups.com
See what dag posted about .bashrc vs .bash_profile




--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages