----- Original Message ----- > 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? > - 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. > 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? > 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. I've added environment variable support recently, I'll mention it on the feature page. > Mirek > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- Regards, Bohuslav "Slavek" Kabrda. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
