Prev: FAQ 8.38 How do I timeout a slow event?
Next: Errors during PersistentPerl Compilation
From: Peter J. Holzer on 30 Dec 2009 11:08
On 2009-12-30 08:44, Dirk Heinrichs <dirk.heinrichs(a)online.de> wrote:
> Ben Morrow wrote:
>> Quoth Tad McClellan <tadmc(a)seesig.invalid>:
>>> Wanna-Be Sys Admin <sysadmin(a)example.com> wrote:
>>> > Peng Yu wrote:
>>> >
>>> >> Since my perl is installed in a nonstandard location, I have to use '/
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Please re-read the solution offered...
>
> The offered solution was simply wrong, so what Tad wrote is perfectly valid.
> The right solution is to add the "nonstandard" location to $PATH, so that
> env can find perl there.

Using /usr/bin/env and relying on the PATH is not a good idea:

* Perl scripts are often called with a minimal PATH (cron jobs, CGI
scripts, etc.). Then the perl executable won't be found.
* The sysadmin may install a new perl executable in a directory which
appears earlier in the path - then the wrong executable will be
found.
* In some situations manipulation of the path may pose a security risk.

In short, I think a script should be as self-contained as possible.
Relying on the PATH often leads to trouble and can easily be avoided.

hp
From: Peter J. Holzer on 30 Dec 2009 12:20
On 2009-12-30 15:26, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote:
>>>>>> "Ruud" == Ruud <rvtol+usenet(a)xs4all.nl> writes:
>
>Ruud> I prefer -w in scripts too, because it enforces warnings on the included
>Ruud> code.
>
> So you want to spend time debugging someone else's code? :)
>
> I put "use warnings" on the code I write while I'm writing it. I'm presuming
> the authors of other modules put use warnings on their code while they're
> writing it.
>
> Keep in mind that "use warnings" has value *only* while coding. It has no
> practical value in production,

That assumes that coding and production are completely separate - that
at one poin in time coding is finished, the program is complete (and
bug-free) and then it will go into production and never be changed
again.

This is - unfortunately - not the case for my code. Sometimes my code is
buggy, sometimes requirements change. Warnings in production code can be
a valuable tool in detecting those cases.

hp

From: Peter J. Holzer on 31 Dec 2009 06:47
On 2009-12-30 21:13, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
> On 2009-12-30, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
>>> The right solution is to add the "nonstandard" location to $PATH, so
>>> that env can find perl there.
>>
>> Using /usr/bin/env and relying on the PATH is not a good idea:
>>
>> * Perl scripts are often called with a minimal PATH (cron jobs, CGI
>> scripts, etc.). Then the perl executable won't be found.
>> * The sysadmin may install a new perl executable in a directory which
>> appears earlier in the path - then the wrong executable will be
>> found.
>> * In some situations manipulation of the path may pose a security risk.
>>
>> In short, I think a script should be as self-contained as possible.
>> Relying on the PATH often leads to trouble and can easily be avoided.
>
> Cannot agree here. Your arguments show that "it is has possible
> drawbacks", not that it "is not a good idea".

In 20 years of system administration I have seen quite a lot of scripts
break because they had avoidable dependencies on the environment.
Sometimes in catastrophic ways.


> There are VERY STRONG positive side to having a script in a form which
> does not require you to explain to your grandmother how to exit vi... :-( :-)

OTOH this was never a problem.

My grandmother never used a computer in her live. My parents are
unlikely to ever use a script which they haven't installed with the
package manager.

And even if they do, the script should come with a Makefile which does
the right thing on "make install". It is the responsibility of a
software author to make their software robust, especially if it is
intended to be used by users who don't know how to exit vi.

hp

From: Tad McClellan on 31 Dec 2009 21:32
Wanna-Be Sys Admin <sysadmin(a)example.com> wrote:
> Tad McClellan wrote:
>
>> Wanna-Be Sys Admin <sysadmin(a)example.com> wrote:
>>> Peng Yu wrote:
>>>
>>>> Since my perl is installed in a nonstandard location, I have to use
>>>> '/
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> usr/bin/env perl'. I also what to use it with '-w'. I'm wondering
>>>> how to do it.
>>>>
>>>> Currently, I have the following error.
>>>>
>>>> $ head -n 1 ./main.pl
>>>> #!/usr/bin/env perl -w
>>>> $ ./main.pl
>>>> /usr/bin/env: perl -w: No such file or directory
>>>
>>> just use "use warnings;" which offers some advantages. Keep the env
>>> the
>>> same. Problem solved.
>>
>>
>> Please re-read the problem statement...
>
> I did, please re-read my response,


I missed the env in your response.

I apologize.


--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
From: Xho Jingleheimerschmidt on 1 Jan 2010 15:41
Ben Morrow wrote:
>
> (Not that I think this is a good solution. env(1) on the #! line is a
> security risk, since you don't know what's in the PATH; I've always
> found it a little disconcerting that python recommends
>
> #!/usr/bin/env python
>
> in the standard docs.)

I don't really see that this is all that much of a problem, at least not
in the general case. If you actually don't know what is in your path,
and you don't trust that your path has been set by a benevolent
sys-admin, then it seems like you are already screwed six ways from
Sunday, Perl or no Perl.

Xho
First  |  Prev  | 
Pages: 1 2
Prev: FAQ 8.38 How do I timeout a slow event?
Next: Errors during PersistentPerl Compilation