Re^3: Net::SSH2 and Trapeze, in-band authentication

I don't think the get_channel sub is reliable. If for whatever reason the data coming from the remote side is delayed, the non-blocking read call is going to return undef and any additional data will be lost.

Doing non-blocking IO with Net::SSH2 is far from being easy. You can see how it is done in my module Net::SSH::Any using select to check when new data arrives on the SSH socket (the code is here, see the __io3 method).

Another possibility that usually works is to send all the input data (login and commands) in one go and then capture everything in blocking mode until you get and EOF. You will have to add an additional command to close the connection from the remote side (i.e. exit).

Comment on Re^3: Net::SSH2 and Trapeze, in-band authentication Select or Download Code

Replies are listed 'Best First'.
Re^4: Net::SSH2 and Trapeze, in-band authentication by FloydATC (Deacon) on Apr 05, 2013 at 12:07 UTC
Yes, the data is indeed delayed and the non-blocking call does return undef every now and then. This is why I call get_channel() repeatedly from get_response() and accumulate the results until I see the prompt. The reason I can't do blocking calls is because the channel will never EOF or return a short buffer unless I tell the host to "exit" and terminate the connection. Not cool if I want to execute more commands based on the output from a previous command. -- Time flies when you don't know what you're doing	[reply]

Replies are listed 'Best First'.

Re^4: Net::SSH2 and Trapeze, in-band authentication
by FloydATC (Deacon) on Apr 05, 2013 at 12:07 UTC

The reason I can't do blocking calls is because the channel will never EOF or return a short buffer unless I tell the host to "exit" and terminate the connection. Not cool if I want to execute more commands based on the output from a previous command.

-- Time flies when you don't know what you're doing

[reply]