bundle-exec - Execute a command in the context of the bundle
bundle exec[--keep-file-descriptors] command
This command executes the command, making all gems specified in the
Gemfile(5) available to
require in Ruby programs.
Essentially, if you would normally have run something like
rspec spec/my_spec.rb, and you want to use the gems specified
Gemfile(5) and installed via bundle install(1), you
bundle exec rspec spec/my_spec.rb.
bundle exec does not require that an executable is
available on your shell's
If you use the
--binstubs flag in bundle install(1), Bundler will
automatically create a directory (which defaults to
containing all of the executables available from gems in the bundle.
bin/rspec spec/my_spec.rb is identical
bundle exec rspec spec/my_spec.rb.
bundle exec makes a number of changes to the shell environment,
then executes the command you specify in full.
bundlefrom inside a command invoked by
rackup) for your bundle on
$RUBYOPT, which makes sure that Ruby programs invoked in the subshell can see the gems in the bundle
It also modifies Rubygems:
gemmethod to be a no-op if a gem matching the requirements is in the bundle, and to raise a
Gem::LoadErrorif it's not
Gem.refreshto be a no-op, since the source index is always frozen when using bundler, and to prevent gems from the system leaking into the environment
Gem.bin_pathto use the gems in the bundle, making system executables work
Any Ruby code that opens a subshell (like
system, backticks, or
automatically use the current Bundler environment. If you need to shell out to
a Ruby command that is not part of your current bundle, use the
with_clean_env method with a block. Any subshells created inside the block
will be given the environment present before Bundler was activated. For
example, Homebrew commands run Ruby, but don't work inside a bundle:
Bundler.with_clean_env do `brew install wget` end
with_clean_env is also necessary if you are shelling out to a different
bundle. Any Bundler commands run in a subshell will inherit the current
Gemfile, so commands that need to run in the context of a different bundle also
need to use
Bundler.with_clean_env do Dir.chdir "/other/bundler/project" do `bundle exec ./script` end end
Bundler provides convenience helpers that wrap
exec, and they
can be used like this:
Bundler.clean_system('brew install wget') Bundler.clean_exec('brew install wget')
At present, the Rubygems plugin system requires all files
rubygems_plugin.rb on the load path of any installed
gem when any Ruby code requires
rubygems.rb. This includes
executables installed into the system, like
Since Rubygems plugins can contain arbitrary Ruby code, they commonly end up activating themselves or their dependencies.
For instance, the
gemcutter 0.5 gem depended on
If you had that version of gemcutter installed (even if
you also had a newer version without this problem), Rubygems
gemcutter 0.5 and
If your Gemfile(5) also contained
json_pure (or a gem
with a dependency on
json_pure), the latest version on
your system might conflict with the version in your
Gemfile(5), or the snapshot version in your
If this happens, bundler will say:
You have already activated json_pure 1.4.6 but your Gemfile requires json_pure 1.4.3. Consider using bundle exec.
In this situation, you almost certainly want to remove the
underlying gem with the problematic gem plugin. In general,
the authors of these plugins (in this case, the
gem) have released newer versions that are more careful in
You can find a list of all the gems containing gem plugins by running
ruby -rubygems -e "puts Gem.find_files('rubygems_plugin.rb')"
At the very least, you should remove all but the newest
version of each gem plugin, and also remove all gem plugins
that you aren't using (
gem uninstall gem_name).