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

Miloslav Trma─Ź mitr at volny.cz
Thu Jan 24 19:13:29 UTC 2013


Hello,
On Thu, Jan 24, 2013 at 7:58 AM, Bohuslav Kabrda <bkabrda at redhat.com> wrote:
> ----- Original Message -----
>> 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?
>>
>
> - So let's consider creating a new Rails application. You create it using "rails new app". Rails have shebang #!/usr/bin/ruby, so that would imply always using MRI and you'd have to figure out how to actually run it with JRuby. The problem here is, that a Rails application generated by Ruby and JRuby looks differently. Specifically, their Gemfiles are different - the implementation independent Gems are the same, but extension Gems (e.g. DB drivers, JS runtime wrapper) are not the same.
> - The user might not care which interpreter is used, but a developer wanting to test the application under MRI/JRuby appreciates a fast and easy way how to test under both.

That's definitely a valid use case; why is it better for the user to
run (./script/rails _jruby_) instead of (/usr/bin/jruby
./script/rails)?  The latter should be more portable, and requires no
effort to implement.

>> 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 *".
>
> It's true, that it would run actually run _jruby_ and ignore the file, although I'm not sure what security risks that brings. Could you be more specific?

I don't really have a specific concern; it just doesn't "feel right"
to override application behavior this way (and, from a security point
of view, "composition kills" - having harmless corner cases in
packages A, B, C may mean that there is a vulnerability when A,B,C are
used together).

Looking at the rubypick script, it seems to actually override "-h",
which would be very user-noticeable.
    Mirek


More information about the devel mailing list