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