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. 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
