Seth Willits wrote:
> I'm now using non-blocking and am trying to figure out when the
> remote side sends an eof.
When libssh2_channel_eof() returns true. Never otherwise.
> I figured eof and read returning 0 would go hand in hand,
That's not correct. As the man page for libssh2_channel_read
documents, 0 bytes returned means no data. It does not mean EOF.
> 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.
No. The example you showed demonstrated that when a channel is EOF
read will return 0, but you are now suddenly inferring the reverse,
which is simply incorrect.
> I've noticed it does depend on the command I'm running though.
Obviously. Different commands close their output at different times.
> (Looking at the server, cat isn't still running.)
If the channel was used for executing a single program and that
program is no longer running and you have read all data from the
channel (stdout and stderr) then yes libssh2_channel_eof() should
return true, and if not there is a problem somewhere.
> Is this a difference of whether or not the remote program actually
> closes its stdout before exiting or something similar perhaps?
As you probably know a file descriptor (like stdout) always belongs
to a process and thus ceases to exist when the process ends. So the
situation is clearly that the process has not ended yet.
> (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.)
Sorry, but that's not correct. Please look at the documentation
and/or play around more with the examples.
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2012-05-17