Yuri
2020-Jan-11 01:37 UTC
Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
This is perhaps a problem with the documentation. This command: $ ssh <remote-host-name> echo? '`hostname`' gets the strings "echo" and "`hostname`" as arguments, but on the server side "echo" is run with the argument "remote-host-name". The ssh manpage says: > If a command is specified, it is executed on the remote host instead of a login shell. If "echo" is interpreted as a login shell, who interprets "`hostname`" as "remote-host-name" then, and why? I found that in order to pass the string to the command run on the remote host verbatim it is necessary to escape every character in it, but it isn't clear why should this be necessary. Perhaps this should be explained in the manpage. Yuri
Darren Tucker
2020-Jan-11 09:38 UTC
Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
On Sat, 11 Jan 2020 at 12:46, Yuri <yuri at rawbw.com> wrote:> If "echo" is interpreted as a login shell, who interprets "`hostname`" > as "remote-host-name" then, and why? >Echo is not used as a login shell. In both cases it uses your shell, the difference being that in the "ssh foo" case it runs a shell with arguments indicating it's an interactive login (ie a "login shell" which is indicated by a leading "-" in its argv, and usually enables features like job control). In the other case, it's run via the shell using $SHELL -c "your command".> > I found that in order to pass the string to the command run on the > remote host verbatim it is necessary to escape every character in it, > but it isn't clear why should this be necessary. >The command you give is always handled on the server by your shell in some fashion. It has to be, because SSH only specifies an opaque string for the remote command, so without doing so you would not be able to specify arguments at all. -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Yuri
2020-Jan-11 09:59 UTC
Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
On 2020-01-11 01:38, Darren Tucker wrote:> The command you give is always handled on the server by your shell in some > fashion. It has to be, because SSH only specifies an opaque string for the > remote command, so without doing so you would not be able to specify > arguments at all.It's not obvious why does it have to be this way. ssh sends the command as an array of strings. The first string is the command, and the subsequent strings are arguments. It can easily call the same command with the same arguments on the remote host. Also this sentence from the man page seems to be false: > If a command is specified, it is executed on the remote host instead of a login shell. Login shell still interprets the command. Interestingly, the shell process isn't running on the remote host, the command is a direct child of sshd. Yuri
Yuri
2020-Jan-12 19:29 UTC
Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
Regardless of what the ssh specification says, the ability to run commands verbatim is very useful, and can be implemented with a new dedicated argument, for example -z. The specification can be like this: ???? -z ???????????? Disable argument expansion. When the command is run remotely, ???????????? ssh passes arguments to the remote command verbatim, as they ???????????? were supplied, without any expansions. If the command is a full ???????????? path, it would be run on the target with the arguments as they were ???????????? supplied. If the command is a relative path, it would be run in the ???????????? user's home directory. Otherwise the command would be resolved ???????????? through the PATH variable. In all cases, the arguments would be ???????????? passed to the command exactly as they were supplied to the ssh ???????????? command. Yuri
Thorsten Glaser
2020-Jan-12 19:41 UTC
Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
On Sun, 12 Jan 2020, Yuri wrote:> dedicated argument, for example -z. The specification can be like this:The wording could need some translation by a native speaker, but the idea of this feature request is certainly sound. Of course you?d lose the ability to run multiple commands, redirect I/O, etc. when using your proposed flag. bye, //mirabilos -- tarent solutions GmbH Rochusstra?e 2-4, D-53123 Bonn ? http://www.tarent.de/ Tel: +49 228 54881-393 ? Fax: +49 228 54881-235 HRB 5168 (AG Bonn) ? USt-ID (VAT): DE122264941 Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Maybe Matching Threads
- Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
- Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
- Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
- Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?
- Why are the arguments supplied for the command run through ssh interpreted by shell before they are passed to the command on the server side?