can't get it to run the rvm ruby

[ericcj]

despite having the rvm stuff in my bash_profile and bashrc i can't get this hook to use the rvm ruby when called with the shebang #!/usr/bin/env ruby. seems to work fine at the terminal, does git abandon all environment variables before running hooks?

beezo:~ ej$ /usr/bin/env ruby -v ruby 1.9.3p374 (2013-01-15 revision 38858) [x86_64-darwin12.2.1]

beezo:~ ej$ git --version git version 1.7.12.4 (Apple Git-37) hub version 1.10.4

[cypher]

Looks like it prepends PATH with /usr/bin (/usr/libexec/git-core:/usr/bin to be exact), thus the system Ruby is the first one it finds.

I can think of two solutions right now: Either use the complete path to your version of Ruby as the shebang (e.g. /usr/local/rvm/bin/ruby-1.9.2-p290@projectX, see Using RVM with Cron for more details), or use a wrapper shell script that sources your RVM environment before execing the Ruby script.

[ericcj]

using the path to the rvm ruby as the shebang isn't enough since below we do "which ruby". you can't actually use the wrapper scripts as shebangs either, they require being passed the ruby script as an argument. we also use "erb" without any path setup.

i can get everything to work by manually replacing that line with:

/Users/ej/.rvm/wrappers/default/erb -xT - views/admin/users/index.erb | /Users/ej/.rvm/wrappers/default/ruby -wc

but it'd be nice to generalize. i guess we could do some hackery around looking if there's a ${HOME}/.rvm/wrappers/default like we do with rbx. there's a confusing git issue about whether this is even supposed to be the case: https://github.com/magit/magit/issues/498#issuecomment-9570082

[thelucid]

I'm having the same issue with rbenv, anyone found a clean solution other than referencing a specific version? https://github.com/sstephenson/rbenv/issues/374#issuecomment-16026039

[cypher]

I think pretty much the only solution would be to restore the original $PATH by removing the first two entries. That way, rvm/rbenv should be used to get whatever Ruby you set.

However, a possible downside is that this may have unintended side effects, like some git porcelain suddenly not working any more. And it's brittle as hell, since Git may change this behavior in future.

I've just pushed 8c302a1, could you test with that commit and see if it works then? If it does, then maybe we can come up with a sane way to restore the original $PATH without possibly breaking everything.

[thelucid]

This doesn't work unfortunately as should the ruby file contain and syntax only available in a specific version (such as 1.9's hash syntax vs 1.8's traditional syntax) then by the time the path gets replaced, the error has already happened e.g.

#!/usr/bin/env ruby

if ENV['PATH'] =~ %r{\A/usr/libexec/git-core:/usr/bin:?(.*)\z}
  ENV['PATH'] = $1
end
puts "RUBY: #{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}, PATH: #{ENV['PATH'].inspect}, RBENV_VERSION: #{ENV['RBENV_VERSION']}"

something = { foo: 'bar' }

...in this case, if the system version is 1.8 and the rbenv version is 1.9, there will still be a parse error before the new path can take effect.