Seems to be an issue if there is a space anywhere in the file path of the directory

[danmanstx]

so running ./hello-1.0.0-osx/hello works

but changing the directory with

mv hello-1.0.0-osx hello\ 1.0.0-osx

and running

./hello\ 1.0.0-osx/hello

causes

/Users/danmanstx/Desktop/ruby/traveling-ruby-hello-demo/hello 1.0.0-osx/lib/ruby/bin/ruby: line 14: 1.0.0-osx/lib/ruby/lib/ruby/gems/2.1.0: No such file or directory

I am really running into this when using a packaged ruby inside of something that resides in Application Support on Mac OS X. Above is just a simplified example.

[FooBarWidget]

It looks like it's caused by the fact that we set RUBYOPT in order to require a file. This filename contains a space, which borks the Ruby command line options parser.

One solution is to put restore_environment.rb in the standard Ruby load path so that we don't have to reference the full filename.

[danmanstx]

I've tried some different things, but can't seem to get anything working. What is the best way to do that @FooBarWidget? and Thanks so much for your help and this awesome project! 🍻

[FooBarWidget]

Move restore_environment.rb to lib/ruby/lib/2.1.0/. Then change the RUBYOPT option in lib/ruby/bin/ruby_environment to -rrestore_environment (without the full path).

[danmanstx]

Thanks @FooBarWidget moving restore_enviroment.rb to lib/ruby/lib/2.1.0/

and then changing lib/ruby/bin/ruby_environment from

echo RUBYOPT=\"-r$ROOT/lib/restore_environment\"
echo GEM_HOME="$ROOT/lib/ruby/gems/2.1.0"
echo GEM_PATH="$ROOT/lib/ruby/gems/2.1.0"

to

echo RUBYOPT="-rrestore_environment"
echo GEM_HOME=\"$ROOT/lib/ruby/gems/2.1.0\"
echo GEM_PATH=\"$ROOT/lib/ruby/gems/2.1.0\"

worked 👍

[ezekg]

Are there any disadvantages to doing this? If not, why don't we make this a default? This is especially problematic when you bundle a Ruby for an OSX app, as those are very likely to contain spaces.

Either that, or it might be worth adding something like my Rakefile below to the tutorials,

# ...

def create_package(target, os_type = :unix)
  package_dir = "resources/bin/#{PACKAGE_NAME}-#{PACKAGE_VERSION}-#{target}"
  sh "rm -rf #{package_dir}"
  sh "mkdir -p #{package_dir}/lib/app"
  sh "cp #{PACKAGE_MAIN} #{package_dir}/lib/app/"
  sh "mkdir -p #{package_dir}/lib/ruby"
  sh "mkdir -p packaging/"
  sh "tar -xzf packaging/traveling-ruby-#{TRAVELING_RUBY_VERSION}-#{target}.tar.gz -C #{package_dir}/lib/ruby"
  if os_type == :unix
    sh "cp packaging/wrapper.sh #{package_dir}/#{PACKAGE_NAME}"
  else
    sh "cp packaging/wrapper.bat #{package_dir}/#{PACKAGE_NAME}.bat"
  end
  sh "mkdir -p packaging/vendor/"
  sh "cp -pR packaging/vendor #{package_dir}/lib/"
  sh "cp Gemfile Gemfile.lock #{package_dir}/lib/vendor/"
  sh "mkdir #{package_dir}/lib/vendor/.bundle"
  sh "cp packaging/bundler-config #{package_dir}/lib/vendor/.bundle/config"

  if os_type == :unix

    # Hack to get paths containing spaces to behave correctly
    # @see https://github.com/phusion/traveling-ruby/issues/38
    sh %Q{sed -i '' -e 's|RUBYOPT=\\\\"-r$ROOT/lib/restore_environment\\\\"|RUBYOPT=\\\\"-rrestore_environment\\\\"|' #{package_dir}/lib/ruby/bin/ruby_environment}
    sh %Q{sed -i '' -e 's|GEM_HOME="$ROOT/lib/ruby/gems/2.1.0"|GEM_HOME=\\\\"$ROOT/lib/ruby/gems/2.1.0\\\\"|' #{package_dir}/lib/ruby/bin/ruby_environment}
    sh %Q{sed -i '' -e 's|GEM_PATH="$ROOT/lib/ruby/gems/2.1.0"|GEM_PATH=\\\\"$ROOT/lib/ruby/gems/2.1.0\\\\"|' #{package_dir}/lib/ruby/bin/ruby_environment}
    sh "mv #{package_dir}/lib/ruby/lib/restore_environment.rb #{package_dir}/lib/ruby/lib/ruby/2.1.0/restore_environment.rb"

    sh "tar -czf #{package_dir}.tar.gz #{package_dir}"
  else
    sh "zip -9r #{package_dir}.zip #{package_dir}"
  end
end

# ...

Is this also a potential issue with Windows? I haven't had a chance to test that.

[FooBarWidget]

It's simply because I haven't had time yet.