4

I'm not sure if this belongs here or somewhere else (SuperUser?) but anyway:

I've got two Ruby scripts, one which requires Ruby 2.0 (A) and another which requires 1.8 (B). A needs to call B with a forked processes. A is something like this:

require "fileutils"
require "json"

...

`name_of_B`

B is an executable script with a shebang, starting like this:

#!/Users/user_name/.rvm/rubies/ruby-1.8.7-p374/bin/ruby
require 'rubygems'
require 'json'

...

I use RVM to manage my Ruby versions:

> rvm list
rvm rubies

   ruby-1.8.7-p374 [ i686 ]
   ruby-1.9.3-p448 [ x86_64 ]
=* ruby-2.0.0-p247 [ x86_64 ]

I run A with:

> ruby name_of_A

but end up with:

/Users/jacobevelyn/.rvm/gems/ruby-2.0.0-p247/gems/json-1.8.1/lib/json/ext/parser.bundle: [BUG] Segmentation fault
ruby 1.8.7 (2013-06-27 patchlevel 374) [i686-darwin12.5.0]

Any thoughts on what I can do? I don't know a whole lot about gems but it appears that B tries to look at gems installed under Ruby 2.0, rather than 1.8. (Yes, I've run gem install json under 1.8 already.) Obviously the scripts are more complicated than they appear here and absolutely cannot be ported or combined (this doesn't mean I don't want to, it means I can't for my use case), otherwise I would.

JacobEvelyn
  • 3,901
  • 1
  • 40
  • 51

2 Answers2

1

Call:

result = `\path\to\ruby_1_8 \path\to\ruby_1_8_script.rb`

This will use the correct ruby binary to execute the script that expects it. The result is saved into the var.

You can call which ruby to find the version of the ruby in your current directory. Go to your project / source dir and call it to see the version (presumably Ruby 2) that you're using for the main app. Then, go to your old project / repo (associated with the 1.8 script) and run it again. Hopefully that will show you the path to Ruby 1.8. If not, try it from root (/). Or use RVM to confidently switch to Ruby 1.8 and then call it there to get the path.

I've never used RVM much. If it is confused, and filters things through the wrong gem set, etc, then you may need instead to switch to rbenv. Also, you may need to use its own functions to display the true path to the Ruby 1.8 binary (i.e. maybe it messes with which?) Again, I don't RVM.

New Alexandria
  • 6,951
  • 4
  • 57
  • 77
  • This still doesn't work, unfortunately. I'm running `/Users/user_name/.rvm/rubies/ruby-1.8.7-p374/bin/ruby name_of_B` and getting the same error. And I've tried `rvm use 1.8 ; name_of_B ; rvm use 2.0` but then I get: "RVM is not a function, selecting rubies with 'rvm use ...' will not work." and then the segfault again. – JacobEvelyn Nov 19 '13 at 21:50
  • Does that command work outside of Ruby 2.0? Like if you call it from the command line? – New Alexandria Nov 19 '13 at 21:52
  • RVM won't work inside Ruby 2.0 because RVM is loaded through your shell startup script. You could try sourcing that file (`.bashrc`?) but I've never done that before. – New Alexandria Nov 19 '13 at 21:53
1

you need to change the shebang to:

#!/Users/user_name/.rvm/wrappers/ruby-1.8.7-p374/ruby

it will not only use that ruby but also its gems.

in case you use bundler (Gemfile) you might also need to wrap the command invocation in:

Bundler.with_clean_env do
  ...
end

which will reset loaded bundler environment

mpapis
  • 52,729
  • 14
  • 121
  • 158
  • The shebang here didn't seem to work quite right, but if A calls B with `/Users/user_name/.rvm/wrappers/ruby-1.8.7-p374/ruby name_of_B` it does. Strange. – JacobEvelyn Nov 20 '13 at 06:42