I believe most of the problem that people are having here is that there is a misconception about what blocking *really* means.
Blocking means a read from the *stream* will wait until there is data. Not necessarily all the data from the application -- but *some*. So it won't help you at all if you're executing a command that doesn't write to stdout, or writes a whole lot of data.
So there are 2 problems:
1. If you need to know that a silent program is done via ssh2_exec, you'll need to signal it to yourself. ssh2_exec will *not* block execution until the command is done executing. And 2 consecutive ssh2_execs may execute asynchronously. You could also log into a shell via ssh2_shell and parse up to the next prompt -- but that's overkill. You can also do this by adding on some sort of sentinel at the end of your command, such as echo "@," and then block on reads until you see a "@." Ensure "@" won't appear in the output, or escape the output via some encoding mechanism if you can't do that.
2. If the program takes awhile, you have the same problem. You need to read until you're done. So you need a sentinel value like the above.
3. Sleep() is just a bad idea here. Commands rarely take the same amount of time to execute a command twice. It may be OK if you're doing *one* thing and can just wait 5 seconds. But that's not cool if it's something you're doing in a loop.
Hope this helps!
