Ruby 1.8 and 1.9 living in harmony

I’m running on OSX, and using MacPorts for all my un-Apple needs. So, no, getting Ruby 1.9 installed was not complex at all, the suffix is the default in MacPorts, so I just ended up with a ruby1.9 executable.

The kicker comes because Rails, and all its little generator friends, do one of two things. Either they are just hardcoded to use #!/usr/bin/env ruby or they set that line to whatever version of Ruby you happen to be using when you install/generate/make them the first time, which will be either what I’ve just written or #!/usr/bin/env ruby1.9 or (like rails) an actual hard coded path to your MacPorts ruby executable.

Ok, not really a big problem there, until you want to test your application, generator, plugin, gem, whatever against the other ruby on your system. What do you do? Go through and make sure you change all the relevant shebangs? Works fine until you miss one. You’re really testing your sed fu, not your Ruby fu.

And then what happens when, like me, you’re just so used to typing irb or ri that you’re constantly tripping over the “Oh, yeah, that’s over in the 1.9 stuff.” problem?

Well, then you know it’s time to roll out your bash fu. Ewk!

I rolled up these bash functions to switch my MacPorts installation from 1.8 to 1.9 by taking all the binaries that are part of the ruby macports install and moving them to suffixed files, and then symlinking the bare names to either 1.8 or 1.9 (which IMHO should always be how languages are installed).

<script src="http://gist.github.com/310185.js "></script>

So, dependencies? It depends on you having macports - it uses that to get the list of files that have been added to the relevant bin directory. You could replace that in the for loop with something else to give you those filenames.

That’s it.

Hmm, or it would be it if I said: run r18 to switch to Ruby 1.8 and run r19 to switch to Ruby 1.9. Also - warning - this runs sudo, so understand what you’re running before typing in your password.