Greetings – I’m debugging a way to call a command-line executable as a
server. In normal life it behaves like grep, reading lines from stdin
and printing responses to stdout. So I’m debugging the Ruby wrapper on
grep, as the original takes a long time to load (thus the whole
exercise). Here’s what I got – but it swallows the first line of input
and doesn’t respond! Why?
#!/usr/bin/env ruby
require ‘optparse’
require ‘ostruct’
class Server
def initialize(cmd_line)
puts “starting server with the following command line:”
puts cmd_line @pipe = IO.popen cmd_line, “r+”
end
def process(sent)
return nil if sent.nil? or sent =~ /^\s+$/
The first thing that comes to mind is that you are writing the sent
text to the pipe and then immediately calling readlines; is that
enough time for grep to process its work and write the result back to
the pipe?
Also, by “but it swallows the first line of input and doesn’t
respond!”, do you mean that you are not able to write anymore text
(indicating that readlines might be blocking) or just that it never
shows grep’s result?
Hey Szymon – good to see you here! If, instead of “grep something”, I
give it a Ruby program which reads and writes lines, it works OK. I
wonder what’s different between these:
– a.rb:
IO.popen(“ruby b.rb”, “r+”) do |f|
STDIN.each_line do |x| @write = f.puts x.to_s @read = f.gets
puts “back: #{@read}”
end
end
– b.rb:
STDOUT.sync = true
def readWrite
while @string = gets @string.chomp!
puts “received => #{@string}”
end
end
readWrite
$ ruby a.rb
/z/aha/ru/popen ruby a.rb
abra
back: received => abra
cadabra
back: received => cadabra
…
– can enter strings, they’re echoed back.
Now, let’s call “grep abra” instead of b.rb:
– call-grep.rb:
IO.popen(“grep abra”, “r+”) do |f|
STDIN.each_line do |x|
puts “sending: #{x}” @write = f.puts x.to_s @read = f.gets
puts “back: #{@read}”
end
end
I guess you should make sure to flush the pipe caches before trying to
get output from the background process. If the data you sent in the
first place is still sitting there, you won’t get anything back…
Anyway, I had better luck with using two separate threads for writing
and reading to/from the pipe. This one below just hangs because the
buffers fill up and it can’t send more data before reading from the
output. Note that this is on Cygwin on WinXP SP2 - the amount of data
which triggers the deadlock may wary on other systems.
open(’|tr [a-z] [A-Z]’, ‘w+’) do |tr|
30000.times{tr.puts ‘hehe’}
tr.close_write
puts tr.read
end
But this one echoes back the HEHE’s just as expected:
open(’|tr [a-z] [A-Z]’, ‘w+’) do |tr|
Thread.new do
30000.times{tr.puts ‘hehe’}
tr.close_write
end
puts tr.read
end
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.