Cannot run ruby with chruby

[fxn]

I have GraalVM uncompressed under ~/graalvm-0.27 and ~/.rubies/truffleruby symlinked as documented in https://github.com/graalvm/truffleruby/blob/master/doc/user/ruby-managers.md#chruby and get this error:

$ ruby
realpath: No such file or directory
argv[0]=ruby

chruby is 0.3.9.

Note that there is no intermediate shell script, ruby is resolved by Bash directly as

$ which ruby
/Users/fxn/.rubies/truffleruby/bin/ruby

and that file is a binary executable

$ file /Users/fxn/.rubies/truffleruby/bin/ruby
/Users/fxn/.rubies/truffleruby/bin/ruby: Mach-O 64-bit executable x86_64

Let me also add that invoking said binary using a full path works

$ ~/.rubies/truffleruby/bin/ruby -v
truffleruby 0.27, like ruby 2.3.3 <Java HotSpot(TM) 64-Bit Graal VM 1.8.0_121-b13 with Graal> [darwin-x86_64]

[eregon]

Interesting, this is specific to macOS as there we need to use a real binary to circumvent the fact that macOS does not allow multiple levels of interpreters through execve() (see #154).

In this case, the value passed to argv[0] is just ruby so it is not trivial to locate the absolute executable (it needs a manual PATH lookup).

[eregon]

I opened PR #492 for a fix.

As a workaround for GraalVM 0.27 you can:

cd graalvm-0.27/jre/languages/ruby/bin
rm truffleruby
ln -s truffleruby.sh truffleruby    

[fxn]

Awesome Benoit. Checked the patch with Darwin's docs, interesting how in C you need to call _NSGetExecutablePath() twice.

Confirm that the workaround works.

[fxn]

Not so fast! :)

RubyGems seems to generate executables with this shebang

#!/Users/fxn/graalvm-0.27/jre/languages/ruby/bin/truffleruby

Since the symlink makes that a shell script, it is not able to interpret Ruby:

/Users/fxn/.gem/truffleruby/2.3.3/bin/jekyll: line 9: require: command not found

If this gets too complicated do not worry, I can wait for the next version with #492 applied.

[eregon]

Right, the workaround above does not fix the problem that macOS does not allow multiple levels of interpreters through execve, which notably happens when running gem binaries directly.
Prefixing with ruby -S ... like ruby -S jekyll ... is a workaround for the limitations of this workaround 😅
The real fix is #492 of course.