OS X 10.10 no longer includes Ruby 1.8 about command-t

[lilyball]

Incidentally, the failure mode here is quite horrible. If I try and use Command-T with Ruby 2.0, I get a forkbomb (ruby calling sh calling ruby, ad infinitum)

[wincent]

Command-T doesn't require 1.8 (or any specific version of Ruby). It will use whatever Ruby you compile it with (and that's generally based on what you have in your PATH, potentially manipulated by tools such as rvm and rbenv, at build time). The added catch here is that you must compile it with the same version of Ruby that Vim links against, or it won't work.

I gather you're not on a clean install of 10.10, so you should just rebuild Command-T against the system Ruby:

cd path/to/your/command-t/install
cd ruby/command-t
ruby --version # verify you're using 2.0.0-p451
vim -c 'ruby puts "#{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}"' # should print 2.0.0-p451
ruby extconf.rb
make clean
make

[lilyball]

Hrm, the documentation referenced Ruby 1.8 multiple times and I thought that was the required version. But it appears that was a misinterpretation of the docs.

I already tried recompiling command-t itself. I'll try again though.

[wincent]

Yeah, the docs say this:

On OS X Snow Leopard, Lion and Mountain Lion, the system comes with Ruby 1.8.7
and all recent versions of MacVim (the 7.2 snapshots and 7.3) are linked
against it.

On OS X Mavericks, the default system ruby is 2.0, but MacVim continues to
link against 1.8.7, which is also present on the system at:

  /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

I'll update the docs with info about Yosemite as well.

[lilyball]

You're right, this time it worked without forkbombing. I'm not sure what went wrong last time, but forkbombing is the behavior I was seeing with Homebrew trying to run its Ruby 1.8-compatible code on Ruby 2.0, so that's what I thought was going on here.

I'll leave this open to cover updating the docs I guess.

[wincent]

Deal. 👍