Non-interactive shell expand alias

Question

I'm having trouble getting aliases to expand on my hosting account when I run a command like:

ssh user@server "bash -c \"alias\""

My .bashrc file is:

echo .bashrc
# .bashrc

shopt -s expand_aliases

# Source global definitions (commenting this out does nothing)
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi

# User specific aliases and functions
alias php="php55"
alias composer="php ~/bin/composer.phar"

When I run the above ssh command, I do see ".bashrc" echo'd. But if I try to run aliases, I get nothing.

I could try "bash -ic", but this is actually in a script that I can't easily change, and I want to know why this isn't working.

Output of ssh user@server "bash -c \"shopt\""

.bashrc
autocd          off
cdable_vars     off
cdspell         off
checkhash       off
checkjobs       off
checkwinsize    off
cmdhist         on
compat31        off
compat32        off
compat40        off
dirspell        off
dotglob         off
execfail        off
expand_aliases  off
extdebug        off
extglob         off
extquote        on
failglob        off
force_fignore   on
globstar        off
gnu_errfmt      off
histappend      off
histreedit      off
histverify      off
hostcomplete    on
huponexit       off
interactive_comments    on
lithist         off
login_shell     off
mailwarn        off
no_empty_cmd_completion off
nocaseglob      off
nocasematch     off
nullglob        off
progcomp        on
promptvars      on
restricted_shell        off
shift_verbose   off
sourcepath      on
xpg_echo        off

Output of ssh user@server "bash -c \"echo $SHELL\""

.bashrc
/bin/bash

Answer 1

From the bash(1) man page:

Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt (see the description of shopt under SHELL BUILTIN COMMANDS below).

Answer 2

The shell that you get when you execute a command remotely with SSH is neither an interactive shell nor a login shell:

$ ssh server 'bash -c "echo $-"'
chsB

(there's no i and no l in the response)

In Bash's case that means that none of the usual initialization files are read.

You can force the remote shell to be a login shell by adding -l to your Bash invocation, which means that it would parse the first one of ~/.bash_profile, ~/.bash_login, and ~/.profile that it can find, searching in that order, but not ~/.bashrc. This means that you will have to put your aliases in one of those files instead.

Answer 3

I had the same problem, and at first shopt -s expand_aliases didn't seem to help. What I've found out is that this options should be set before adding the actual aliases. So if aliases are created before your .bashrc sets the expand_aliases options, they won't be available. Therefore, you should load (or reload) aliases after setting the option.

Answer 4

bash(1) says

...

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists.

...

An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option.

so, obviously, you either source .bashrc manually or run it with -i

if aliases are all you need i would recommend splitting them away in e.g. .aliases and then source that from both .bashrc and your script, just in case stuff creeps up in .bashrc that may break your script, as it often happens

Answer 5

You can solve any problem by entering:

if [ -f /etc/skel/.bashrc ]; then . /etc/skel/.bashrc; fi

at the first line.