On Thu, Jan 24, 2013 at 10:21 AM, Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
>> 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.
Right, having a single shebang line that "always works" is a valid
concern. That doesn't necessarily mean that this /usr/bin/ruby script
should handle some command-line arguments specially.
>> 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.
When viewed as a shell behavior, it's nothing new. The thing that is
new is the response of the application (e.g. rubypick taking over -h /
--help as I mentioned in the other mail).
This is ultimately up to FPC, isn't it? Anyway, let me suggest that
the environment variable approach is better overall (similar UI, and
unlike command-line arguments environment variables are automatically
propagated to child processes), the command-line arguments are more
intrusive and risky, so using _only_ environment variables would
handle all use cases that have been mentioned so far and avoid the
major risks.
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
