Re^5: Splitting up quoted/escaped command line arguments

in reply to Re^4: Splitting up quoted/escaped command line arguments
in thread Splitting up quoted/escaped command line arguments

Why do you say that these commands won't work unless passed to a shell vs calling ssh directly?

Because it's obvious they have been written to be parsed by a shell.

Can you assure that there would be no entries using redirections, pipes, back-quotes, logical operators, variables, wildcards, etc.? Those are features that any intermediate shell user employs frequently.

Comment on Re^5: Splitting up quoted/escaped command line arguments

Replies are listed 'Best First'.
Re^6: Splitting up quoted/escaped command line arguments by Tommy (Chaplain) on Feb 11, 2014 at 22:16 UTC
Because it's obvious they have been written to be parsed by a shell. OK, no problem, I'll repeat myself in case you missed it in my earlier response to this issue. It's already assumed that a shell is going to be used on the remote side of the connection (as in the OP). There's nothing in the OP that would be interpreted as a shell escape locally; even if there were shell escapes present--passing it to exec in indirect object notation negates the possibility that it gets sent to the shell because each argument is passed as a literal argument to the invocant. Remote shell: yes. Localhost: no. It is the local machine where the shell is to be avoided. Can you assure that there would be no entries using redirections, pipes, back-quotes, logical operators, variables, wildcards, etc.? Yes. Actually that is assured. Anything like that is supposed to be wrapped in a shell script and sent+executed on the remote host. Still, this is a moot point because of the specific way I'm calling exec. Tommy A mistake can be valuable or costly, depending on how faithfully you pursue correction	[reply]

Replies are listed 'Best First'.

Re^6: Splitting up quoted/escaped command line arguments
by Tommy (Chaplain) on Feb 11, 2014 at 22:16 UTC

Because it's obvious they have been written to be parsed by a shell.

OK, no problem, I'll repeat myself in case you missed it in my earlier response to this issue. It's already assumed that a shell is going to be used on the remote side of the connection (as in the OP). There's nothing in the OP that would be interpreted as a shell escape locally; even if there were shell escapes present--passing it to exec in indirect object notation negates the possibility that it gets sent to the shell because each argument is passed as a literal argument to the invocant. Remote shell: yes. Localhost: no. It is the local machine where the shell is to be avoided.

Can you assure that there would be no entries using redirections, pipes, back-quotes, logical operators, variables, wildcards, etc.?

Yes. Actually that is assured. Anything like that is supposed to be wrapped in a shell script and sent+executed on the remote host. Still, this is a moot point because of the specific way I'm calling exec.

Tommy
A mistake can be valuable or costly, depending on how faithfully you pursue correction

[reply]

In Section Seekers of Perl Wisdom