Proposed F19 Feature: JRuby 1.7 - JRuby is an alternative Ruby implementation
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 =
> 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) , 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.
More information about the devel