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

Miloslav Trmač mitr at volny.cz
Wed Jan 23 17:59:14 UTC 2013


On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> = Features/JRuby 1.7 =
> https://fedoraproject.org/wiki/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.
   Mirek


More information about the devel mailing list