[TxMt] Re: TextMate 1.5 and Ruby 2.0.0

Allan Odgaard mailinglist@textmate.org wrote:

On Mar 6, 2013, at 20:21, Matt Neuburg matt@tidbits.com wrote:

...

Ruby 2.0.0 is causing further trouble, on this line:

io = IO.for_fd(ENV['TM_ERROR_FD'].to_i)

This generates "Bad file descriptor".

What about this:

IO.for_fd(2) << "test\n"

Does that work?

If it works, try this code as well:

rd, wr = IO.pipe
fork do
  io = IO.for_fd(wr.to_i)
  io << "test\n"
  io.close
end
puts rd.gets

...

don't know how TM_ERROR_FD is set or what might be wrong with it as a file descriptor (it's just a number).

It is setup by TextMate.executor and the number is the file descriptor which is the write-end of a pipe created.

Very cool, thanks! The problem is that that doesn't fit in with RubyMate's way of processing the error message. We are in SharedSupport/Bundles/Ruby.tmbundle/Support/RubyMate/catch_exception.rb. Here, the error message is parsed and is wrapped in some HTML before being fed into the IO object whose number comes from TM_ERROR_FD. That IO object is evidently piped into TextMate's output window, where it appears formatted. If we feed the HTML to just any old IO (such as 2), it isn't formatted; it appears as raw HTML in the output window.

It's odd, isn't it? What could there possibly be about Ruby 2.0.0 that would make the int value of TM_ERROR_FD a "bad file descriptor" when it is a perfectly good file descriptor under previous versions of Ruby?

I tried just running this script as a way of seeing what file descriptors are good and what file descriptors are bad:

(-200..200).each do |n| begin IO.for_fd(n) << "#{n} test\n" puts "#{n} succeeded" rescue puts "#{n} failed" end end

Only 1 and 2 are good. But TM_ERROR_FD is 9 (though that particular number is just an implementation detail on any given run).

Mysterious, eh?

By the way, I see now that this same question has been asked before:

http://lists.macromates.com/textmate/2012-April/034878.html

m.