-
-
Notifications
You must be signed in to change notification settings - Fork 190
Troubleshooting
There may be cases when a particular command ends up using the system ruby although a later version is specified as default using chruby
.
If this happens, refer these:
What 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 .zshrc
or .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 gem env
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 rvm
or 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 .zshrc
and/or .bash_profile
. If you want to use the rubies installed via rbenv
(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.
Consider a 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 bundle
or gem
under this setting, the executable at /usr/bin
gets evoked even though the correct ruby
is set via chruby
.
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.