`for_fd': Bad file descriptor #60

ioquatix opened this Issue Dec 10, 2013 · 8 comments


None yet

4 participants


When running any script when the system ruby is 2.0+, the following appears in the output window systematically:

catch_exception.rb:12: in `for_fd': Bad file descriptor (Errno::EBADF)
    from /Users/samuel/Library/Application Support/TextMate/Managed/Bundles/Ruby.tmbundle/Support/RubyMate/catch_exception.rb:12:in `block in <top (required)>'
untitled 2:24: in `<main>': undefined method `[]' for nil:NilClass (NoMethodError)
@sorbits sorbits closed this in ad7d85c Dec 10, 2013

This version of Ruby has been deprecated, why not try and fix the actual bug?

textmate member

Isn't it pretty easy, just have a monkey patch for RUBY_VERSION >= "2.0"?

Regarding 1.8.x being deprecated, it isn't my opinion, but the officially disclosed state: https://www.ruby-lang.org/en/news/2011/10/06/plans-for-1-8-7/

textmate member

Until TextMate only runs on Mavericks and higher we must keep support for 1.8 which means work-arounds and testing twice for hundreds of bundle items. There simply isn't any benefit to all that work until we can just switch fully over to 2.0.

There is nothing stopping bundle authors from using 2.0 in any bundle item that would benefit from a feature that needs 2.0, we just aren't going to be using it in any of the 'main' bundles for now.


@infininight Generally, I agree with you. But this is one specific point, which is easily made cross-version compatible, and wouldn't require extensive testing to confirm that it is working correctly.. that being said, other things might break with 2.0 but I haven't found any other issues thus far.

This bug report is really an indication of what is to come. Ruby 2.0 is inevitable, and so the sooner you figure out how to support it correctly (even if it means a few version specific code paths for now) and allow users to test it (perhaps optionally) the better, IMHO.

In other words, this bug isn't really fixed by this patch, but it's effects have been mitigated such that this issue will need to be revisited again in the future. Better to prepare for a future where 1.8 isn't available, sooner rather than later, IMHO. Less pain for users, in my experience, if things just work. It is highly possible that this "fix" won't work when Mac OS X 10.10 is released, for example.

textmate member

I don't think I've made any estimates about the number of version specific code paths anywhere. I've simply said I've found one issue (reported here) but I haven't personally run into any others.

Apple may or may not remove 1.8.7 in Mac OS X 10.10 - that gives you at least 6-12 months to sort this problem out at a minimum. At a maximum? I'd be surprised if Apple doesn't remove Ruby 1.8 sooner rather than later, given that it has security bugs and other problems.

The reason to spend time on 2.0 support now is to ensure a seamless transition for users in the future, and also now - from what I've read online, other users having problems too.

The next best alternative is to simply add if RUBY_VERSION > "1.8.7"; throw UnsupportedPlatformError; end - at least make it clear to users who are trying to use Ruby 2.0 that it is not supported, and a lot of this confusion would be alleviated.

Finally, perhaps now would be a good time to start documenting the bugs in order to prepare for the updates required for 2.0 - you could, for example, tag all the bugs relating to Ruby 1.8.7/2.0 so that it is clear what needs to be revisited to fix things in the future if you don't plan to address those issues now.


@ioquatix I'd say you should send a PR that adds a comment with the solution ready for when ruby 2.0 / mavericks will become required in TM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment