Dne 23.1.2013 18:59, Miloslav Trmač napsal(a):
On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik <jreznik@xxxxxxxxxx> 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.
I'll try elaborate why we chose this approach.
What problem are the _mri_/_jruby_ parameters solving?
Generally, we are trying to get into Fedora more Ruby interpreters, we
are currently speaking about Ruby MRI, JRuby and Rubinius in near
future. Therefore, we would like to allow the user to have the one he
chose or all of them if (s)he wants. For that, we need to have something
which can always interpret script with #!/usr/bin/ruby and that is going
to be our rubypick, which will be always capable to select the best Ruby
interpreted available on the computer.
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.
Yes, you are right. Instead of just "rake" user can run "jruby -S rake"
to run rake by JRuby. To be honest, I needed quite a lot of thinking to
realize that this is also possible.
This is just another convenient option IMO and it is actually nothing
new, because you can run "rake _0.8.7_" to specify, that you'd like to
run Rake of that specific version. So we just build on this.
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?
Yes, as long as you don't care, you don't need magic parameter.
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.
Yes, I agree that you should be worried:
$ ls *
ls: cannot access *: No such file or directory
$ touch -- -l
$ ls *
total 0
-rw-rw-r--. 1 user user 0 Jan 24 10:10 -l
But as my example shows, it is nothing new. And as Slavek wrote,
environment variables are already supported.
Vít
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
