>From: net-ssh-devel-bounces@rubyforge.org >Date: 09/28/2004 23:33:59 >Subject: Re: [Net-ssh-devel] Simple question > >ville.mattila@stonesoft.com wrote: >> Hello again, >> >> I''ve now cooked up the solution solution below and it does about whatI>> need. Note that this >> is work in progess so the interpreter thread is not terminated and so >> on... >> There is one problem still . If I''m giving command that does notgenerate>> output >> the thing blocks for exaple expect("cd /var", ""). The reason is that >> SSHStdoutPipe#bytes_available >> does not work as expected it always returns 0. I tried to fix thismyself>> but got lost. > >[snip excellent solution] > >Looks great! I haven''t tried it yet, but I will. :) I''ll take a look and >see what I can find out about the #bytes_available method...Thanks! Please could look the bytes_available soon.> >Sorry I''ve been so quiet on the Net::SSH front...it''s my #1 priority >after RubyConf, though, I promise! > >In fact...I''m toying with the idea of ripping Net::SSH apart and putting >it back together again using Copland. It seems a prime candidate for >benefiting from IoC, and I think it would actually make the code >possible to reasonably unit test! Imagine that... :)I''ve been following your preach about IoC. You certainly have got my intrest, but I haven''t had time to study the IoC concept yet. If the IoC brings good unittests covarage then go for it!> >So, that''s probably what I''ll start doing around mid-October, unless >anyone has a good reason why I *shouldn''t* do it. The only possible >drawback I can think of is that it will create a dependency on >Copland...but in my mind, that''s not really a bad thing. :)Hey, you are the author of Net:SSH, so if you think that IoC brings long time benefit, then I don''t see any problems not to rewrite. Nowadays package depency isn''t a big issue anymore, because of excellent rpa and rubygems... - Ville
ville.mattila@stonesoft.com wrote:> >>From: net-ssh-devel-bounces@rubyforge.org >>Date: 09/28/2004 23:33:59 >>Subject: Re: [Net-ssh-devel] Simple question>>Looks great! I haven''t tried it yet, but I will. :) I''ll take a look and >>see what I can find out about the #bytes_available method... > > > Thanks! Please could look the bytes_available soon. >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. 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). 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. 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.) Hope that made some sense. Let me know if I should try to explain anything differently. - Jamis -- Jamis Buck jgb3@email.byu.edu http://www.jamisbuck.org/jamis