我正在尝试从我的Windows机器启动我的Ruby项目,当我通过SSH进入我的流浪盒时,导航到领班,然后尝试运行foreman start
我收到以下错误。
01:54:14 web.1 | started with pid 12002
01:54:15 web.1 | BUNDLE-EXEC(1) BUNDLE-EXEC(1)
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | NAME
01:54:15 web.1 | bundle-exec - Execute a command in the context of the bundle
01:54:15 web.1 |
01:54:15 web.1 | SYNOPSIS
01:54:15 web.1 | bundle exec [--keep-file-descriptors] command
01:54:15 web.1 |
01:54:15 web.1 | DESCRIPTION
01:54:15 web.1 | This command executes the command, making all gems specified in the Gemfile(5) available to require in Ruby programs.
01:54:15 web.1 |
01:54:15 web.1 | Essentially, if you would normally have run something like rspec spec/my_spec.rb, and you want to use the gems specified in the Gem‐
01:54:15 web.1 | file(5) and installed via bundle install(1) bundle-install.1.html, you should run bundle exec rspec spec/my_spec.rb.
01:54:15 web.1 |
01:54:15 web.1 | Note that bundle exec does not require that an executable is available on your shell´s $PATH.
01:54:15 web.1 |
01:54:15 web.1 | OPTIONS
01:54:15 web.1 | --keep-file-descriptors
01:54:15 web.1 | Exec in Ruby 2.0 began discarding non-standard file descriptors. When this flag is passed, exec will revert to the 1.9 behav‐
01:54:15 web.1 | iour of passing all file descriptors to the new process.
01:54:15 web.1 |
01:54:15 web.1 | BUNDLE INSTALL --BINSTUBS
01:54:15 web.1 | If you use the --binstubs flag in bundle install(1) bundle-install.1.html, Bundler will automatically create a directory (which
01:54:15 web.1 | defaults to app_root/bin) containing all of the executables available from gems in the bundle.
01:54:15 web.1 |
01:54:15 web.1 | After using --binstubs, bin/rspec spec/my_spec.rb is identical to bundle exec rspec spec/my_spec.rb.
01:54:15 web.1 |
01:54:15 web.1 | ENVIRONMENT MODIFICATIONS
01:54:15 web.1 | bundle exec makes a number of changes to the shell environment, then executes the command you specify in full.
01:54:15 web.1 |
01:54:15 web.1 | · make sure that it´s still possible to shell out to bundle from inside a command invoked by bundle exec (using $BUNDLE_BIN_PATH)
01:54:15 web.1 |
01:54:15 web.1 | · put the directory containing executables (like rails, rspec, rackup) for your bundle on $PATH
01:54:15 web.1 |
01:54:15 web.1 | · make sure that if bundler is invoked in the subshell, it uses the same Gemfile (by setting BUNDLE_GEMFILE)
01:54:15 web.1 |
01:54:15 web.1 | · add -rbundler/setup to $RUBYOPT, which makes sure that Ruby programs invoked in the subshell can see the gems in the bundle
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | It also modifies Rubygems:
01:54:15 web.1 |
01:54:15 web.1 | · disallow loading additional gems not in the bundle
01:54:15 web.1 |
01:54:15 web.1 | · modify the gem method to be a no-op if a gem matching the requirements is in the bundle, and to raise a Gem::LoadError if it´s not
01:54:15 web.1 |
01:54:15 web.1 | · 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
01:54:15 web.1 | leaking into the environment
01:54:15 web.1 |
01:54:15 web.1 | · Override Gem.bin_path to use the gems in the bundle, making system executables work
01:54:15 web.1 |
01:54:15 web.1 | · Add all gems in the bundle into Gem.loaded_specs
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | Shelling out
01:54:15 web.1 | Any Ruby code that opens a subshell (like system, backticks, or %x{}) will automatically use the current Bundler environment. If you
01:54:15 web.1 | 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
01:54:15 web.1 | created inside the block will be given the environment present before Bundler was activated. For example, Homebrew commands run Ruby,
01:54:15 web.1 | but don´t work inside a bundle:
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | Bundler.with_clean_env do
01:54:15 web.1 | `brew install wget`
01:54:15 web.1 | end
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | Using with_clean_env is also necessary if you are shelling out to a different bundle. Any Bundler commands run in a subshell will
01:54:15 web.1 | inherit the current Gemfile, so commands that need to run in the context of a different bundle also need to use with_clean_env.
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | Bundler.with_clean_env do
01:54:15 web.1 | Dir.chdir "/other/bundler/project" do
01:54:15 web.1 | `bundle exec ./script`
01:54:15 web.1 | end
01:54:15 web.1 | end
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | Bundler provides convenience helpers that wrap system and exec, and they can be used like this:
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | Bundler.clean_system(´brew install wget´)
01:54:15 web.1 | Bundler.clean_exec(´brew install wget´)
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | RUBYGEMS PLUGINS
01:54:15 web.1 | At present, the Rubygems plugin system requires all files named rubygems_plugin.rb on the load path of any installed gem when any Ruby
01:54:15 web.1 | code requires rubygems.rb. This includes executables installed into the system, like rails, rackup, and rspec.
01:54:15 web.1 |
01:54:15 web.1 | Since Rubygems plugins can contain arbitrary Ruby code, they commonly end up activating themselves or their dependencies.
01:54:15 web.1 |
01:54:15 web.1 | For instance, the gemcutter 0.5 gem depended on json_pure. If you had that version of gemcutter installed (even if you also had a
01:54:15 web.1 | newer version without this problem), Rubygems would activate gemcutter 0.5 and json_pure <latest>.
01:54:15 web.1 |
01:54:15 web.1 | If your Gemfile(5) also contained json_pure (or a gem with a dependency on json_pure), the latest version on your system might con‐
01:54:15 web.1 | flict with the version in your Gemfile(5), or the snapshot version in your Gemfile.lock.
01:54:15 web.1 |
01:54:15 web.1 | If this happens, bundler will say:
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | You have already activated json_pure 1.4.6 but your Gemfile
01:54:15 web.1 | requires json_pure 1.4.3. Consider using bundle exec.
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | In this situation, you almost certainly want to remove the underlying gem with the problematic gem plugin. In general, the authors of
01:54:15 web.1 | these plugins (in this case, the gemcutter gem) have released newer versions that are more careful in their plugins.
01:54:15 web.1 |
01:54:15 web.1 | You can find a list of all the gems containing gem plugins by running
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | ruby -rubygems -e "puts Gem.find_files(´rubygems_plugin.rb´)"
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | 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
01:54:15 web.1 | using (gem uninstall gem_name).
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 |
01:54:15 web.1 | March 2016 BUNDLE-EXEC(1)
01:54:16 web.1 | exited with code 0
01:54:16 system | sending SIGTERM to all processes
所有Procfile保持的是:bundle exec padrino start -h 0.0.0.0
当我尝试在我的OSX设备上运行它时,我能够很好地启动该过程。它只是从我的Windows电脑我遇到这个。有没有人碰到这个或知道我错过了什么?
答案 0 :(得分:0)
显然,在Windows上使用puTTY的区别,以及OSX内置的vagrant ssh需要padrino start -h 0.0.0.0
左右的引号。
因此,修复程序正在将Procfile中的bundle exec padrino start -h 0.0.0.0
更改为bundle exec 'padrino start -h 0.0.0.0'
。