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 !