On May 10, 2012, at 2:47 AM, Peter Stuge wrote:
>> channel = libssh2_channel_open_session(session);
>> libssh2_channel_set_blocking(channel, 1);
>> libssh2_channel_exec(channel, "touch 'test.tmp'");
>> libssh2_channel_eof(channel); // 0
>> libssh2_channel_read(channel, buffer, bufferSize); // 0, no blocking
>
> It does block, but it returns when the remote side reports EOF. Exec
> sleep 10s instead of touch for comparison.
>
>
>> libssh2_channel_eof(channel); // 1
>> libssh2_channel_read(channel, buffer, bufferSize); // 0, no blocking
>
> Since the channel is now EOF, nothing can be read anymore.
Related to this…
I'm now using non-blocking and am trying to figure out when the remote side sends an eof. I figured eof and read returning 0 would go hand in hand, but I'm experiencing read returning 0 consistently over and over in successive calls, but libssh2_channel_eof always returning 0 as well. I would have figured that, like in the above example, if read returns 0, it has reached EOF, otherwise it would still be returning EAGAIN.
I've noticed it does depend on the command I'm running though. For instance, if I run uptime read gives me back some bytes, and then eof returns 1 soon afterwards. Same with pwd. If I run 'cat somefile' however, read returns 0 over and over, but eof never becomes 1. (Looking at the server, cat isn't still running.) Is this a difference of whether or not the remote program actually closes its stdout before exiting or something similar perhaps?
(Really this more of a curiosity than a necessity to know because if I get a 0 I know the remote side is done executing, so it effectively is eof.)
Thanks.
-- Seth Willits _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2012-05-17