----- Original Message -----
Hello,
On Thu, Jan 24, 2013 at 7:58 AM, Bohuslav Kabrda <bkabrda(a)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.
To me, typing "rails _jruby_" is more comfortable than "jruby
/usr/bin/rails" (yep, I agree that this is a matter of opinion). Also, I'm not
sure whether I mentioned a Ruby way of running certain versions of Gems executables, so
I'll mention it again [1] (scroll a bit lower to see invoking specific version of rake
with "rake _0.7.3_"). This is how we got the idea in the first place and why we
think it would be quite convenient for ruby devs.
>> 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.
Yes, the idea is to also provide the info about rubypick when using ruby -h, but that
doesn't break anything. Ruby's help is printed after rubypick's anyway, so I
really don't see what harm this may do.
Mirek
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Regards,
Bohuslav "Slavek" Kabrda.
[1]
http://guides.rubygems.org/command-reference/#gem_install