#! /usr/bin/perl preferred
Ralf Corsepius
rc040203 at freenet.de
Sun Aug 30 16:12:01 UTC 2009
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
More information about the perl-devel
mailing list