Using alias by executing command remotely with ssh

Question

shopt -s expand_aliases
ttmp="SUCCESS"
alias aliased_command='echo $ttmp'

I can use alias remotely by adding the above lines to .bashrc file.

[USER@REMOTESERVER ~]$ ssh MYSERVER aliased_command
SUCCESS

Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt

expand_aliases option allows for non-interactive shells to use aliases.

However, when I run:

[USER@REMOTESERVER ~]$ ssh MYSERVER echo $-
himBH

it seems that running a remote command through ssh is using an interactive shell.(i is contained)

Is this right?

If right, why does this need expand_aliases option?

If wrong, if ssh SERVER COMMAND uses a non-interactive shell, why does ssh MYSERVER COMMAND read .bashrc file of MYSERVER when a non-interactive shell doesn't read .bashrc file?

cf) quoting command results a different output

[USER@REMOTESERVER ~]$ ssh MYSERVER 'echo $-'
hBc

Any link, comment appreciated.

Answer 1

There are at least two aspects:

1. Quoting

Unquoted $- is expanded by your local shell. Note the local ssh can build shell code (to run on the remote side) from multiple arguments it gets. When you did ssh MYSERVER echo $-, the remote shell got echo himBH. The himBH string came from your local shell. When you did ssh MYSERVER 'echo $-', the remote shell got echo $-.

See How to execute complex command line over ssh and my answer there. I won't repeat everything here. The most important thing:

To be in control of what the remote shell will get as $command_line_built_by_ssh, you need to understand, predict and mastermind the parsing and interpreting that happens before. You need to craft your local command, so after the local shell and ssh digest it, it becomes the exact $command_line… you want to execute on the remote side.

A good method is to pass the exact (remote) command to the local ssh as a single argument. This is what you did by ssh MYSERVER 'echo $-' and the single-quotes prevented local expansion. The $- was unquoted in the context of the remote shell.

As a result hBc came from the remote shell. The remote shell was not interactive.

2. Bash tries to be smart

About non-interactive shell sourcing .bashrc, see this another answer of mine:

Twist number 2: Bash attempts to determine when it is being run with its standard input connected to a network connection, as when executed by a SSH server. If Bash determines it is being run in this fashion, it does read and execute commands from ~/.bashrc.

You linked to the Bash documentation. What I'm talking about is under "Invoked by remote shell daemon". There are more twists, see the full linked answer.