in reply to Re^8: SSH to remote subsystem (Net::OpenSSH?)
in thread SSH to remote subsystem (Net::OpenSSH?)

Thankyou @salva. Closing the out pipe worked, but adding a newline didnt. Code snippet below. 
## SEND THE QUERY FOR THE CONFIG
$message = qq~
<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
    <get-config><source><running/></source></get-config>
</rpc>
]]>]]>~;
print $out $message;
close $out;

## PRINT THE RESULTS
while (<$in>) {
    print;
    last if $_ =~ m/\/nf:rpc-reply/;
}
close $in;
waitpid( $pid, 0 );
exit;

[download]

If I wanted to keep the $out pipe open so that further messages could be sent is there some sort of flush (I assume this is what you expected the newline to do) that could be used? I looked at the Net:OpenSSH docs in the open_ex section but dont see anything that suggests this can be done.

If this is not possible should I close and recreate the open_ex for every req/res I send?

Thanks for the prompt response, apologies if the questions are naive, perl newbie.

Replies are listed 'Best First'.
Re^10: SSH to remote subsystem (Net::OpenSSH?)
by salva (Canon) on Sep 10, 2014 at 15:22 UTC
    The returned $out is a regular file handle. You can just set it in autoflushing mode using $out->autoflush(1).
[reply]
[d/l]
      Thanks but unfortunately setting autoflush didnt work. As mentioned previously the close on the $out resulted in the incoming message being printed.

      Can you help me understand why closing one file handle ($out) results in the other file handle ($in) printing output in the while loop?

      Are the file handles tied, is closing one in effect closing the other?

[reply]
        Can you help me understand why closing one file handle ($out) results in the other file handle ($in) printing output in the while loop?

        When you close the $out file handle, the remote process which is reading from the other side gets an EOF and that triggers its 'ok-i-have-the-complete-request-sending-the-response-now' logic.

        In theory, sending the end of record marker should be enough to get the response back, but it is not uncommon for network equipment to have broken SSH implementations. In this case, it seems that it has some buffering issue.

        Delivering of the EOF in SSH is done using a different set of protocol primitives and those are correctly flushing the buffers (otherwise, it would be a useless SSH implementation).

[reply]

In Section Seekers of Perl Wisdom