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

Solution 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).

Solution 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.

Solution 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.

Comments

[Admin]

I've given up and just created symlinks and scripts in ~/bin that do the same thing I wanted with aliases. As long as I export my $PATH as ~/bin:$PATH it works well.

[Admin]

On Ubuntu (16.04 and newer for sure) if you have a ~/.local/bin when the /etc/profile is processed it will automatically add that to your PATH. You can also just . /etc/profile after creating the folder to get it added to your PATH without a reboot or logout/login.

[Matt]

so I see that .bashrc is being sourced. I see the echo line from .bashrc when I run the command. The problem is aliases in that file don't expand.

[Matt]

I do have shopt -s expand_aliases in my .bashrc, but that doesn't seem to work. I'm not sure why not, but I guess this would be the answer normally

[crimson-egret]

@Matt I'm not sure the order of 'events', but did you try making sure the shopt -s expand_aliases is in your .bashrc before the aliases? Certainly, your output in the question shows expand_aliases is off.

[Matt]

Yeah, see the .bashrc in my question. I see the echo line but shopt does show it as off. Maybe there's just some weird server setting that's preventing this, I don't know. I've got a workaround

[Matt]

This sounds like the solution. I'm not even using this server any more so I can't test it, but probably worth upvoting this in case someone else finds the question.

[Daniel Farrell]

probably the .bashrc file was not being sourced by default.