views:

275

answers:

2

Hey guys,

So I installed Ruby 1.9 into /usr/local/bin and kept Ruby 1.8.7 in /usr/bin. Renamed all my 1.8 ruby, rails, rdoc, etc. executables to ruby18, rails18, etc.

So, going ruby --version at the command line gives me:

ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-darwin9.7.0]

If I start up an irb session and look at the $: variable, which shows all locations that are searched for any require or load calls, the list is Ruby 1.8 locations that are part of the OEM Ruby install!

test
/Library/Ruby/Site/1.8
/Library/Ruby/Site/1.8/powerpc-darwin9.0
/Library/Ruby/Site/1.8/universal-darwin9.0
/Library/Ruby/Site
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/powerpc-darwin9.0
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0
.

I thought maybe the irb executable was still pointing to 1.8 so I made sure the shebang was correct and it is:

#!/usr/local/bin/ruby

I guess there's nothing inherently wrong with also searching in those locations for includes, but it looks like those are the only locations - it would never search for even standard libraries in the lib/ruby19 directory. What gives?

Update

If I have Ruby give me the contents of $: directly and skip irb it looks like the list is correct:

ruby -e 'puts $:'

/usr/local/lib/ruby19/1.9.1/test
/usr/local/lib/ruby19/gems/1.9.1/gems/actionmailer-2.3.2/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/actionpack-2.3.2/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/activerecord-2.3.2/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/activeresource-2.3.2/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/activesupport-2.3.2/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/daemons-1.0.10/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/eventmachine-0.12.8/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/rack-1.0.0/bin
/usr/local/lib/ruby19/gems/1.9.1/gems/rack-1.0.0/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/rails-2.3.2/bin
/usr/local/lib/ruby19/gems/1.9.1/gems/rails-2.3.2/lib
/usr/local/lib/ruby19/gems/1.9.1/gems/thin-1.2.2/bin
/usr/local/lib/ruby19/gems/1.9.1/gems/thin-1.2.2/lib
/usr/local/lib/ruby19/site_ruby/1.9.1
/usr/local/lib/ruby19/site_ruby/1.9.1/i386-darwin9.7.0
/usr/local/lib/ruby19/site_ruby
/usr/local/lib/ruby19/vendor_ruby/1.9.1
/usr/local/lib/ruby19/vendor_ruby/1.9.1/i386-darwin9.7.0
/usr/local/lib/ruby19/vendor_ruby
/usr/local/lib/ruby19/1.9.1
/usr/local/lib/ruby19/1.9.1/i386-darwin9.7.0
.

So, that sounds like the wrong version of irb is being invoked. But like I said, the shebang line appears to be talking to the correct Ruby executable.

If I invoke irb with ruby directly then I get the correct list of 1.9 includes:

ruby /usr/local/bin/irb

This is really weird...

+1  A: 

Well, what I ended up doing was just logging off the terminal session and starting a new one. Now when I run irb I get the correct list of 1.9 locations.

The terminal sure thought it was running the correct one before, though:

which irb
/usr/local/bin/irb

shrug

Rob Cameron
A: 

Sounds like maybe a case of Bash PATH caching then. In the future, can use hash -r to clear.

rnicholson