On Wed, Jan 16, 2013 at 2:05 PM, Jaroslav Reznik <jreznik(a)redhat.com> wrote:
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