Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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

by salva (Abbot)
on Feb 11, 2014 at 18:30 UTC ( #1074464=note: print w/ replies, xml ) Need Help??


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

But hose commands would not work unless you pass them through a shell!

Or if you prefer to view it from a different angle, you will have to implement in your program all the shell functionality used by those commands!

Update: And BTW, if those commands involve calling ssh, then a shell would be invoked at the remote side. This is an unavoidable feature of the SSH protocol.


Comment on Re^3: Splitting up quoted/escaped command line arguments
Download Code
Replies are listed 'Best First'.
Re^4: Splitting up quoted/escaped command line arguments
by Tommy (Chaplain) on Feb 11, 2014 at 18:37 UTC

    Yes, I'm keenly aware that a shell is going to be invoked on the remote side. That's fine. I need to avoid it on the local machine. Why do you say that these commands won't work unless passed to a shell vs calling ssh directly? The perldocs don't seem to agree with your assertion.

     

    Tommy
    A mistake can be valuable or costly, depending on how faithfully you pursue correction
      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.

        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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1074464]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (14)
As of 2015-07-28 16:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The top three priorities of my open tasks are (in descending order of likelihood to be worked on) ...









    Results (258 votes), past polls