Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

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

by salva (Canon)
on Feb 11, 2014 at 18:30 UTC ( [id://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.

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
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1074464]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (4)
As of 2024-03-29 12:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found