Go to main content

man pages section 1: User Commands

Exit Print View

Updated: Thursday, June 13, 2019
 
 

bundle-exec (1)

Name

bundle-exec - Man page for 'bundle-exec' in section 1

Synopsis

Please see following description for synopsis

Description

TH  "BUNDLE-EXEC" "1" "November 2018" "" "" SH "NAME" bundle-exec
- Execute a command in the context of the  bundle  SH  "SYNOPSIS"
bundle  exec  [--keep-file-descriptors]  command SH "DESCRIPTION"
This command executes the command, making all gems  specified  in
the  [Gemfile(5)][Gemfile(5)]  available  to require in Ruby pro-
grams.  P Essentially, if you would normally have  run  something
like  rspec  spec/my_spec.rb, and you want to use the gems speci-
fied in the [Gemfile(5)][Gemfile(5)] and installed via bundle in-
stall(1)  bundle-install.1.html, you should run bundle exec rspec
spec/my_spec.rb.  P Note that bundle exec does not  require  that
an  executable  is available on your shell's $PATH.  SH "OPTIONS"
TP --keep-file-descriptors 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 --binstubs flag in bundle  install(1)  bundle-install.1.html,
Bundler  will automatically create a directory (which defaults to
app_root/bin) containing all of the  executables  available  from
gems   in  the  bundle.   P  After  using  --binstubs,  bin/rspec
spec/my_spec.rb   is   identical    to    bundle    exec    rspec
spec/my_spec.rb.   SH  "ENVIRONMENT  MODIFICATIONS"  bundle  exec
makes a number of changes to the shell environment, then executes
the  command  you  specify in full.  IP "o" 4 make sure that it's
still possible to shell out to bundle from inside a  command  in-
voked  by  bundle  exec (using $BUNDLE_BIN_PATH) IP "o" 4 put the
directory containing executables (like rails, rspec, rackup)  for
your  bundle  on  $PATH IP "o" 4 make sure that if bundler is in-
voked in the subshell, it uses the same Gemfile (by setting  BUN-
DLE_GEMFILE)  IP  "o"  4  add  -rbundler/setup to $RUBYOPT, 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 "o" 4
disallow loading additional gems not in the bundle IP "o" 4 modi-
fy  the  gem  method to be a no-op if a gem matching the require-
ments is in the bundle, and to raise a Gem::LoadError if it's not
IP "o" 4 Define Gem.refresh 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  "o"  4  Override
Gem.bin_path to use the gems in the bundle,  making  system  exe-
cutables  work IP "o" 4 Add all gems in the bundle into Gem.load-
ed_specs IP "" 0 P Finally, bundle exec also implicitly  modifies
Gemfile.lock  if  the  lockfile  and  the  Gemfile  do not match.
Bundler needs the Gemfile to determine things  such  as  a  gem's
groups,  autorequire,  and  platforms, etc., and that information
isn't stored in the lockfile. The Gemfile and  lockfile  must  be
synced  in  order to bundle exec successfully, so bundle exec up-
dates the lockfile beforehand.  SS "Loading" By default, when at-
tempting  to  bundle  exec to a file with a ruby shebang, Bundler
will Kernel.load that file instead of using Kernel.exec. For  the
vast  majority  of cases, this is a performance improvement. In a
rare few cases, this could cause some subtle  side-effects  (such
as  dependence  on  the exact contents of $0 or __FILE__) and the
optimization can be disabled by  enabling  the  disable_exec_load
setting.   SS  "Shelling out" Any Ruby code that opens a subshell
(like system, backticks, or %x{}) will automatically use the cur-
rent Bundler environment. If you need to shell out to a Ruby com-
mand  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: IP "" 4 nf

Bundler.with_clean_env do
  `brew install wget` end fi IP "" 0 P  Using  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  Gem-
file,  so commands that need to run in the context of a different
bundle also need to use with_clean_env.  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 system and exec, and they can be used like this: IP "" 4 nf

Bundler.clean_system('brew   install   wget')   Bundler.clean_ex-
ec('brew install wget') fi IP  ""  0  SH  "RUBYGEMS  PLUGINS"  At
present,  the  Rubygems  plugin  system  requires all files named
rubygems_plugin.rb on the load path of any installed gem when any
Ruby  code  requires  rubygems.rb.  This includes executables in-
stalled into the system, like rails, rackup, and rspec.  P  Since
Rubygems  plugins  can contain arbitrary Ruby code, they commonly
end up activating themselves or their dependencies.   P  For  in-
stance,  the  gemcutter 0.5 gem depended on json_pure. If you had
that version of gemcutter installed (even if you also had a newer
version  without this problem), Rubygems would activate gemcutter
0.5 and json_pure <latest>.  P 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 Gemfile.lock.  P If
this happens, bundler will say: IP "" 4 nf

You have already activated json_pure 1.4.6 but your  Gemfile  re-
quires json_pure 1.4.3. Consider using bundle exec.  fi IP "" 0 P
In this situation, you almost certainly want to remove the under-
lying  gem  with  the problematic gem plugin. In general, the au-
thors of these plugins (in this case, the gemcutter gem) have re-
leased  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 (gem uninstall gem_name).


See for descriptions of the following attributes:

+---------------+------------------+
|ATTRIBUTE TYPE | ATTRIBUTE VALUE  |
+---------------+------------------+
|Availability   | runtime/ruby-26  |
+---------------+------------------+
|Stability      | Uncommitted      |
+---------------+------------------+

This   software   was   built   from    source    available    at
https://github.com/oracle/solaris-userland.   The original commu-
nity   source    was    downloaded    from     http://cache.ruby-
lang.org/pub/ruby/2.6/ruby-2.6.0.tar.gz

Further  information about this software can be found on the open
source community website at http://www.ruby-lang.org/.