There may be cases when a particular command ends up using the system ruby although a later version is specified as default using
If this happens, refer these:
chruby does is almost minimal when it comes to switching Rubies. It just changes the
PATH variable depending upon the
ruby you specify. For example, when you type
chruby ruby-2.0.0-p247 on the command-line, the
PATH variable (
echo $PATH) will be something similar to:
/Users/<user-name>/.gem/ruby/2.0.0/bin: /Users/<user-name>/.rubies/ruby-2.0.0-p247/lib/ruby/gems/2.0.0/bin: /Users/<user-name>/.rubies/ruby-2.0.0-p247/bin: /usr/local/homebrew/bin: /usr/local/homebrew/sbin: /usr/bin: /bin: /usr/sbin: /sbin: /usr/local/bin: /opt/X11/bin
Note: that I have the rubies installed under
~/.rubies. If you have them installed in a different directory,
ensure you have the
RUBIES=(/path/to/rubies/*) directive in your
.bash_profile and change the
paths here accordingly
You can see that
chruby has added the correct
ruby to the beginning of the
PATH and this is important. If your
PATH variable has extraneous directories listed out or if you have any shell commands/settings that set extra directory names to your
PATH, then some ruby executables might act weird. So, ensure that the
PATH has the correct settings.
Check the output of
This is the output of the command on my machine:
RubyGems Environment: - RUBYGEMS VERSION: 2.0.3 - RUBY VERSION: 2.0.0 (2013-06-27 patchlevel 247) [x86_64-darwin12.4.0] - INSTALLATION DIRECTORY: /Users/<user name>/.gem/ruby/2.0.0 - RUBY EXECUTABLE: /Users/<user name>/.rubies/ruby-2.0.0-p247/bin/ruby - EXECUTABLE DIRECTORY: /Users/<user name>/.gem/ruby/2.0.0/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-darwin-12 - GEM PATHS: - /Users/<user name>/.gem/ruby/2.0.0 - /Users/<user name>/.rubies/ruby-2.0.0-p247/lib/ruby/gems/2.0.0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :backtrace => false - :bulk_threshold => 1000 - "gem" => "--no-rdoc" - REMOTE SOURCES: - https://rubygems.org/
The Gem paths and Ruby paths should be correctly set as per the
ruby you specify. ( Actually, this is what
chruby does — correctly sets the paths. But sometimes, due to incomplete removal of older managers like
rbenv, you might face some issues. )
If you've used
rbenv, ensure that you cleaned up the installation well. Make sure you don't have extra
rbenv instantiations in your
.bash_profile. If you want to use the rubies installed via
ruby-build), you can still do it with
chruby without removing them. All you need to do is set the
RUBIES directive to point to
~/.rbenv/version/* and then, remove the Rbenv initialization options
eval "$(rbenv init -)" export PATH="$HOME/.rbenv/bin:$PATH"
should be removed.
If any of the ruby executables are using a different ruby than what you've specified, the most common reason is that, in your current
PATH, the wrong executable is found first.
Let me explain.
PATH setting like the one below. For some reason,
/usr/bin is always at the beginning.
/usr/local/homebrew/bin: /usr/local/homebrew/sbin: /usr/bin: /bin: /Users/<user-name>/.gem/ruby/2.0.0/bin: /Users/<user-name>/.rubies/ruby-2.0.0-p247/lib/ruby/gems/2.0.0/bin: /Users/<user-name>/.rubies/ruby-2.0.0-p247/bin: /usr/sbin: /sbin: /usr/local/bin: /opt/X11/bin
When you run
gem under this setting, the executable at
/usr/bin gets evoked even though the correct
ruby is set via
Moreover, once you run
bundle, all the environment settings that are specific to that
bundler installation are used for compilation and installation of gems. So, the
gcc and other compilers that are required to compile native extensions may fail.
In such cases, before running an executable, check the location of the executable by running
which <executable name> (For example
which bundle or
which gem ). And the executables should be under
/Users/<user-name>/.gem/ruby/2.0.0/bin/<executable name>. If this is instead set as
/usr/bin/, then that executable will use the system ruby (1.8.7) even if a different ruby is set.
Another caveat with
PATH lookups is that if the executable is not found in the first directories, then the search happens in the other directories listed. This, combined with a faulty
gem env where-in it lists a different
ruby that the one required, might result in invoking a wrong executable.