bundle-exec - bundler-1.9.9 Documentation

." generated with Ronn/v0.7.3 ." github.com/rtomayko/ronn/tree/0.7.3 . .TH “BUNDLE-EXEC” “1” “December 2014” “” “” . .SH “NAME” fBbundle-execfR - Execute a command in the context of the bundle . .SH “SYNOPSIS” fBbundle execfR [--keep-file-descriptors] fIcommandfR . .SH “DESCRIPTION” This command executes the command, making all gems specified in the fBGemfile(5)fR available to fBrequirefR in Ruby programs. . .P Essentially, if you would normally have run something like fBrspec spec/my_spec.rbfR, and you want to use the gems specified in the fBGemfile(5)fR and installed via bundle install(1) fIbundle-install.1.htmlfR, you should run fBbundle exec rspec spec/my_spec.rbfR. . .P Note that fBbundle execfR does not require that an executable is available on your shell's fB$PATHfR. . .SH “OPTIONS” . .TP fB--keep-file-descriptorsfR Exec in Ruby 2.0 began discarding non-standard file descriptors. When this flag is passed, exec will revert to the 1.9 behaviour of passing all file descriptors to the new process. . .SH “BUNDLE INSTALL --BINSTUBS” If you use the fB--binstubsfR flag in bundle install(1) fIbundle-install.1.htmlfR, Bundler will automatically create a directory (which defaults to fBapp_root/binfR) containing all of the executables available from gems in the bundle. . .P After using fB--binstubsfR, fBbin/rspec spec/my_spec.rbfR is identical to fBbundle exec rspec spec/my_spec.rbfR. . .SH “ENVIRONMENT MODIFICATIONS” fBbundle execfR makes a number of changes to the shell environment, then executes the command you specify in full. . .IP “(bu” 4 make sure that it's still possible to shell out to fBbundlefR from inside a command invoked by fBbundle execfR (using fB$BUNDLE_BIN_PATHfR) . .IP “(bu” 4 put the directory containing executables (like fBrailsfR, fBrspecfR, fBrackupfR) for your bundle on fB$PATHfR . .IP “(bu” 4 make sure that if bundler is invoked in the subshell, it uses the same fBGemfilefR (by setting fBBUNDLE_GEMFILEfR) . .IP “(bu” 4 add fB-rbundler/setupfR to fB$RUBYOPTfR, which makes sure that Ruby programs invoked in the subshell can see the gems in the bundle . .IP “” 0 . .P It also modifies Rubygems: . .IP “(bu” 4 disallow loading additional gems not in the bundle . .IP “(bu” 4 modify the fBgemfR method to be a no-op if a gem matching the requirements is in the bundle, and to raise a fBGem::LoadErrorfR if it's not . .IP “(bu” 4 Define fBGem.refreshfR to 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 . .IP “(bu” 4 Override fBGem.bin_pathfR to use the gems in the bundle, making system executables work . .IP “(bu” 4 Add all gems in the bundle into Gem.loaded_specs . .IP “” 0 . .SS “Shelling out” Any Ruby code that opens a subshell (like fBsystemfR, backticks, or fB%x{}fR) will 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 fBwith_clean_envfR 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: . .IP “” 4 . .nf

Bundler.with_clean_env do

    %x`brew install wget`

end . .fi . .IP “” 0 . .P Using fBwith_clean_envfR 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 fBwith_clean_envfR. . .IP “” 4 . .nf

Bundler.with_clean_env do

    Dir\.chdir "/other/bundler/project" do
      `bundle exec \./script`
    end

end . .fi . .IP “” 0 . .P Bundler provides convenience helpers that wrap fBsystemfR and fBexecfR, and they can be used like this: . .IP “” 4 . .nf

Bundler.clean_system('brew install wget') Bundler.clean_exec('brew install wget') . .fi . .IP “” 0 . .SH “RUBYGEMS PLUGINS” At present, the Rubygems plugin system requires all files named fBrubygems_plugin.rbfR on the load path of fIanyfR installed gem when any Ruby code requires fBrubygems.rbfR. This includes executables installed into the system, like fBrailsfR, fBrackupfR, and fBrspecfR. . .P Since Rubygems plugins can contain arbitrary Ruby code, they commonly end up activating themselves or their dependencies. . .P For instance, the fBgemcutter 0.5fR gem depended on fBjson_purefR. If you had that version of gemcutter installed (even if you fIalsofR had a newer version without this problem), Rubygems would activate fBgemcutter 0.5fR and fBjson_pure <latest>fR. . .P If your Gemfile(5) also contained fBjson_purefR (or a gem with a dependency on fBjson_purefR), the latest version on your system might conflict with the version in your Gemfile(5), or the snapshot version in your fBGemfile.lockfR. . .P If this happens, bundler will say: . .IP “” 4 . .nf

You have already activated json_pure 1.4.6 but your Gemfile requires json_pure 1.4.3. Consider using bundle exec. . .fi . .IP “” 0 . .P 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 fBgemcutterfR gem) have released newer versions that are more careful in their plugins. . .P You can find a list of all the gems containing gem plugins by running . .IP “” 4 . .nf

ruby -rubygems -e “puts Gem.find_files('rubygems_plugin.rb')” . .fi . .IP “” 0 . .P 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 (fBgem uninstall gem_namefR).