Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation

Miloslav Trma─Ź mitr at
Wed Jan 23 17:59:14 UTC 2013

On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik <jreznik at> wrote:
> = Features/JRuby 1.7 =

>  What should "/usr/bin/ruby" point to? During standard Gem packaging process,
>  the executable files in Gems get shebangs according to the binary that they
>  are packaged with (Ruby => "/usr/bin/ruby"; JRuby => "/usr/bin/jruby").
>  Therefore executing a Ruby "binary" runs the interpreter that was used for
>  building (or the hardcoded one, which is usually Ruby). Using alternatives
>  for "/usr/bin/ruby" doesn't seem to be a very good option, because Ruby and
>  JRuby are not in fact full alternatives, as they for example cannot use same
>  extension Gems (but it still makes sense to allow executing same binaries
>  with them). Also, alternatives are only switchable on admin level (we want
>  every developer with non-root privileges to be able to choose the
>  interpreter). Therefore Ruby-SIG has come up with solution of having
>  "/usr/bin/ruby" as a bash script (currently called rubypick) [2], that
>  allows user to choose the interpreter as first argument on invocation
>  (_mri_ or _jruby_), if such a parameter is present. Otherwise it falls
>  back to a default. For example invoking "ruby_binary _jruby_ --foo=bar"
>  in fact invokes "/usr/bin/jruby ruby_binary --foo=bar". This bash script
>  will be in a separate package and both Ruby and JRuby will depend on it.
>  Ruby-SIG knows that this feature might be controversial and we wouldn't
>  want it to stop us from bringing JRuby's power to Fedora (if met with a
>  heavy resistance). So if anyone will suggest a more suitable solution,
>  we'll go with it instead of this one.

What problem are the _mri_/_jruby_ parameters solving?
a) If a script or command-line user requires a specific interpreter,
it can just refer to a path of the specific interpreter directly;
using /usr/bin/ruby magic_parameter seems to provide no advantage.
b) If a script or command-line user doesn't care which interpreter is
used, it doesn't need the magic parameter either.
What am I missing?

Changing the semantics of command-line arguments in unexpected ways
really worries me - it has security implications; e.g. creating a file
named _jruby_ would change the semantics of running "my_script *".  If
it really is necessary to have a switch that alters the behavior of
/usr/bin/ruby, could it be an environment variable instead?  It is
usually more difficult for an attacker to manipulate the process
environment than file names.

More information about the devel mailing list