Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^4: Correct way to use Net:SSH2 module

by MikeKulls2 (Novice)
on Mar 21, 2013 at 22:30 UTC ( #1024832=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Correct way to use Net:SSH2 module
in thread Correct way to use Net:SSH2 module

Sorry, I misread your code, I see that you are creating a new channel for each call. The function being called channel instead of createChannel or newChannel threw me :-) With regards my original question, if I connect with shell instead of exec would I be correct in saying there is no way to tell when the end of the response has been received? Why does it not return the prompt? Also, with your code, why does a poll time of 500ms work perfectly well with a command like "ls;sleep 5;ls;"? When I reduce the poll time to 100ms it times out.


Comment on Re^4: Correct way to use Net:SSH2 module
Re^5: Correct way to use Net:SSH2 module
by salva (Monsignor) on Mar 22, 2013 at 08:11 UTC
    Sorry, I misread your code
    My code? I suppose you mean GrandFather code in Re: Correct way to use Net:SSH2 module!

    if I connect with shell instead of exec would I be correct in saying there is no way to tell when the end of the response has been received?

    Yes, if you run a shell, you have to use some heuristic as looking for the prompt or delaying for a while to detect or ensure that the command is done.

    why does a poll time of 500ms work perfectly well with a command like "ls;sleep 5;ls;"? When I reduce the poll time to 100ms it times out

    Because that code is broken!

    As the SSH object is not set to work in non-blocking mode, once some data becomes available in the channel the code gets stuck in the inner loop where read is called until the channel is closed by the remote side. Then, it runs again the outer loop where it gets the channel_closed event and exits.

    When the timeout is set to 100ms, sometimes it will expire before any data from the first ls command arrives and so never entering the inner loop.

      Oh yes, I meant GrandFather's code. I guess the answer is that shell is for humans and programming against it will always be flawed. The number of ways it can fail is quite extensive, eg differences between OSes, differences between versions of the same OS, path not setup correctly, different environment settings etc. With regards to the code being flawed I was wondering the same thing. Basically the only thing stopping it locking up is that the channel is closed.
        Not necessarily, nowadays all UNIX systems follow the POSIX standard so it is possible to write fairly portable shell code. Network equipment (switches, routers, etc.) exposing custom shells, often on top of crippled SSH implementations are another matter.

        In any case, what it is unreliable is talking (via stdio) to a shell running in interactive mode. Using the SSH capability to launch individual commands on the remote host, creating a new channel for every command, is quite reliable.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (7)
As of 2014-10-22 07:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (114 votes), past polls