#! /usr/bin/perl preferred

[Ralf Corsepius]

On 08/28/2009 10:07 PM, Stepan Kasal wrote:
> Hello,
>
> let me explain.  I was told "they are doing this env clenup
> with python scripts don't you want to do it for perl as well?"
Then let me add: The FPC had discussed this topic during its last 
meeting and didn't agree upon the proposal.

cf. 
http://meetbot.fedoraproject.org/fedora-meeting/2009-08-19/fedora-meeting.2009-08-19-16.01.log.html#l-38

for details.


> My hands were quicker than my brain and I did the search.
>
> Only when I was about to post the results, I realized that I'm
> actually not convinced about the issue.
>
> The official reasoning is that if a system tool is written in Python,
> we want to "guarantee" that it works, so we would rather run it with
> Fedora Python, not with a random experimental Python.  Likewise for
> Perl; if logrotate or some such were written in perl, it should just
> work (modulo Fedora Perl bugs), and the whole system should not crash
> just because of a random /usr/local/bin/perl.
Well, yes there are ways for users to shoot themselves into the foot.

As I wrote many times, installing to /usr/local is special, ... don't do 
it unless you know what you are doing ;-)


> Actually, what Chris said seems to support this reasoning:
>> [...], especially as we can't replace the system
>> Perl as it may have OS implications.
Of cause, envs bears some risks to shot yourselves into the foot - it's 
a double side sword, with pros and cons at the same time.

For example, a user might have a customized "perl"-script (e.g. a perl 
wrapper) installed on his $PATH (e.g. to ~/bin), because he isn't root 
on a particular system and is developing a perl application.

> At this point of time, I do not see any flaw in Ralf's reasoning.
> But I do not want to engage in any war.
It's not necessarily a war. Both, allowing and disallowing env come at 
price. It's a descison to balance the pros and cons.


The big question is: Would disallowing env mean be a true improvement 
(e.g. wrt. system robustness and safety) or would it mean a serious 
usability regression wrt. flexibility to developers?

Some people say "this way", others say "that way".


I for one (as a developer), prefer the flexibility env provides and do 
not see serious risks nor do I see many advantages in disallowing "env".

An uneducated user will always be able find ways to shoot himselves into 
the foot and needs to go through a learning curve - This might be an 
unpopular thought, but ... as trivial as it is, it's not avoidable.

> Let's forget about this and return to more important issues.

Ralf