« Trains closed for 5 days
Jackass free for Jackasses using SilverLight »

Set aliases to ruby 1.9

What’s all this debate over the best way to try out Ruby 1.9 in MacOSX? Just install in /usr/local as detailed here and then set aliases in .profile:

alias ruby9="/usr/local/ruby1.9/bin/ruby"
alias irb9="/usr/local/ruby1.9/bin/irb"
alias gem9="/usr/local/ruby1.9/bin/gem"

Et voila.

UPDATE: This will only work for scripts you run directly from the console – it (probably) won’t work for scripts that call other scripts, eg rakefiles, so take care. It makes my playing around easier, but that’s probably all it’s good for.

Tags:

This entry was posted on Sunday, December 30th, 2007 at 9:26 am and is filed under development. You can follow any responses to this entry through the feed. You can leave a response, or trackback from your own site.

4 Responses to “Set aliases to ruby 1.9”

  1. Wincent Colaiuta Says:
    January 3rd, 2008 at 11:30 pm

    Does that actually work?

    ie. what happens when you run a script that runs another script that starts with “#/usr/bin/env ruby” or similar? Doesn’t the second script fall back to the first ruby it finds in your PATH?

    A much more robust and predictable solution seems to me to be:

    export PATH=”/usr/local/ruby1.9/bin:$PATH”

  2. Sho Says:
    January 4th, 2008 at 7:02 am

    What do you mean, “run a script that runs another script”?

    The shebang line is only relevant if you run an executable (chmod +x) script from shell without specifying an intepreter. So yeah, if you’re shell scripting with ruby, and are in the habit of just calling ./script.rb in your shell scripts or cron or something, then it wouldn’t work, no. /usr/bin/env has no idea about aliases you’ve set in .profile.

    But if you are running scripts by explicitly loading ruby and passing the script into it, then it will work, sure. Anything you pull in via require or whatnot will just load into the same instance. Once the script is being interpreted by actual ruby then the shebang line is ignored as a comment.

    Anyway, you’re right, this kind of thing will not work if you’re in the habit of running ruby scripts as executable shell scripts. Just for messing around conveniently, not for writing cross-platform +x shell scripts. You should probably use 1.8.6 for anything like that anyway.

    Let’s test it, though, just to be sure!

    $ touch test.rb
$ cat > test.rb
#!/usr/bin/env ruby
require 'rbconfig'
c = ::Config::CONFIG
version = (c['MAJOR'] + c['MINOR'] + c['TEENY']).to_i
puts version
^D
$ ruby test.rb
186
$ ruby9 test.rb
190
$ /usr/bin/env ruby -v
ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]
$ chmod +x test.rb
$ ./test.rb
186
  3. Wincent Colaiuta Says:
    January 4th, 2008 at 10:28 pm

    What do you mean, “run a script that runs another script”?

    I meant stuff like any script which uses backticks, Kernel#system, or Kernel#exec etc to execute other scripts. One place where this usage pattern probably crops up fairly often is in Rakefiles.

    BTW, your example script could have been just this:

    puts VERSION

  4. Sho Says:
    January 4th, 2008 at 10:50 pm

    Well, I meant it as nothing but a quick hack to play around with 1.9, for those who may not have thought of it, and believed their only option to be one of the much more complex “sandboxing” examples around the web.

    The use cases you’re describing are way beyond that and someone doing that kind of thing may well be better suited using a PATH trick like you mentioned. Personally, for my playing around, typing irb9 or ruby9 to get the interpreter I want is much easier than setting a new PATH every time – your mileage obviously varies, as they say.

    I updated the post to reflect the limited usage of this kind of trick, don’t want to give anyone else the wrong impression.

    Neat trick with VERSION, by the way – I just cut and pasted from that email but it seems that’s a much better way! So thanks for that tip …

Leave a Reply