>
>I just looked into it, and the reason it returns 0 is because it
>contains no data...
>
>Keep in mind the way the SSH protocol works. Multiple channels, run in
>parallel. Without some other thread to keep the channels running, all
>processing basically halts.
>
>The popen3 method I described is a synchronous approach, rather than
>asynchronous. This means that until you call a method, no data is
>transferred. Thus, until you call #read on the output pipe, the pipe
>contains nothing, and thus "bytes_available" will be 0.
Ok, understood. i.e. always 0 bytes available. Maybe the
documentation should warn that bytes_availble
cannot be used with popen3?
>
>So, how to get around this? One way would be to use threads, but I
don''t
>know what kind of side effects that would have (I haven''t spent
much
>time on concurrency issues in Net::SSH yet).
Could you be more spesific about this approach?>
>Another solution would be to use the lower-level
>Net::SSH::Service::Process class directly:
>
>http://net-ssh.rubyforge.org/chapter-4.html#s3
>
>No, it''s not nearly as elegant as the popen3 approach. :( But
because it
>is asynchronous, you don''t have to worry about calls blocking. You
just
>have to create some kind of simple state machine to keep the callbacks
>synchronized.
I''ll use this instead of popen3. It gives me more freedom.
>
>The whole "expect" idea is a great one, and I hope to have some
time to
>spend on it myself in the next few weeks. (But if I start refactoring
>Net::SSH to use Copland, it might be a while longer than that, even.)
It would good to have current netssh codebase as is, and do
coplandized(?), in
own branch. I''ll post expect patch when I get it working.
>
>Hope that made some sense. Let me know if I should try to explain
>anything differently.
Yes I got it. Thanks for explanantions.
- VIlle