How to put '#!/usr/bin/env perl -w' at the beginning of a perlscript?

[Peter J. Holzer]

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

 

[Ilya Zakharevich]

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?

First: as opposed to what?

Second: do not you choose to ignore the fact that a warning from
foreign code has a very good chance to be a consequence of ME "passing
wrong parameters" to that code 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.

First: I do not see how this would favor `use warnings' over -w. (See above.)

Second: I would not agree less. Writing a good test suite increases
the developing time by what? About 50%, maybe?

[Some part of it goes into coding the test suite, some into
debugging false positives from the test suite, and (probably most?)
into debugging real problems; sigh...]

And writing a test suite which covers ALL the branches in the code
would, I presume, add another 1.5x slowdown to the code lifecycle.
(And, due to what follows, it still would not be bullet-proof.) The
only recourse I see is to consider deployment as a part of development
cycle.

Third: we discuss the case when there is dependence on some 3rd
parties code. The installed version of this code may be obsolete; it
may be also bleeding edge buggy. I prefer to get some "stupidly
self-solving" bug reports (which point to problems in 3rd parties code)
to obscure bug reports forcing a remote debugging loop.

Hope this helps,
Ilya

 

[Ilya Zakharevich]

And I think this is a good thing. Getting lots of warnings in code I
haven't written and cannot change[1][2] is not very helpful. And most
modules use "use warnings" anyway, so it's usually redundant (and you
probably should be wary of those that don't use it).

??? Any module caring about backward compatibility would not `use warnings'.

[1] Well, *I* can change it because I'm sysadmin on most of the systems
where my code runs. But that's far from universal.

But PERLLIB *is* universal.

[2] I remember the bad old days of C programming where you could choose
between getting lots of warnings from system header files and turning
off many useful warnings.

This is not my experience with using -w. At least not for a decade.

Yours,
Ilya

 

[Ilya Zakharevich]

You're entitled to your opinion, but it *is* an opinion - it's neither
right nor wrong, by definition.

And would not you like to share with us what was your point?

Ilya

 

[Ilya Zakharevich]

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".

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... :-(

Yours,
Ilya

 

[Andrew DeFaria]

body { font: Helvetica, Arial, sans-serif; } p { font: Helvetica, Arial, sans-serif; } ..standout { font-family: verdana, arial, sans-serif; font-size: 12px; color: #993333; line-height: 13px; font-weight: bold; margin-bottom: 10px; } ..code { border-top: 1px solid #ddd; border-left: 1px solid #ddd; border-right: 2px solid #000; border-bottom: 2px solid #000; padding: 10px; margin-top: 5px; margin-left: 5%; margin-right: 5%; background: #ffffea; color: black; font-family: courier; white-space: pre; -moz-border-radius: 10px; } ..terminal { border-top: 10px solid #03f; border-left: 1px solid #ddd; border-right: 2px solid grey; border-bottom: 2px solid grey; padding: 10px; margin-top: 5px; margin-left: 5%; margin-right: 5%; background: black; color: white; font-family: courier; white-space: pre; -moz-border-radius: 10px; } blockquote[type=cite] { padding: 0em .5em .5em .5em !important; border-right: 2px solid blue !important; border-left: 2px solid blue !important; } blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid maroon !important; border-left: 2px solid maroon !important; } blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid teal !important; border-left: 2px solid teal !important; } blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid purple !important; border-left: 2px solid purple !important; } blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] blockquote[type=cite] { border-right: 2px solid green !important; border-left: 2px solid green !important; } a:link { color: blue; } a:visited { color: darkblue; } a:hover { color: black; background-color: #ffffcc; text-decoration: underline; } a:active { color: red; } On 12/29/2009 03:17 PM, Randal L. Schwartz wrote:




Don't use "-w". Add "use warnings;" early in your script.

Also, /usr/bin/env perl is a hack. You should replace it with your specific perl path.
That's provided your specific Perl doesn't end up being a script (Can you say cqperl?)
--
Andrew DeFaria
A flashlight is a case for holding dead batteries.

 

[Peter J. Holzer]

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

 

[Wanna-Be Sys Admin]

Every system you've seen gives write permission
on /usr/bin to ordinary users?

Nope. I never said this was for /usr/bin. The symlink would (or
should) be from their user's account path, and point that to wherever,
if they were going to use a symlink. This would allow them to run it
on whatever system, and just have to point the one symlink to the
system's Perl install.

I have never seen a system that gives write permission
on /usr/bin to ordinary users...

That's good, I've not either.

errr, like a perl binary perhaps?

perldoc -f symlink

That's one way, yes.

We all think that (except the OP, who has hopefully been converted by
now)

Right. No disagreement there.

You have not addressed the OP's primary problem.

I have.

His binary is not at /usr/bin/perl and may in fact be in yet a
third place when moved to another system.

Yep, so they need to update the shebang, or use env, or create a
symlink, or whatever. They were given several suggested options in
this thread.

 

[Wanna-Be Sys Admin]

Please re-read the problem statement...

I did, please re-read my response, among the other responses that I and
others gave. Anyway, I stated it they want to _keep_ the env shebang
setting and use warnings, that they _can_ do that, and to just use the
warnings module call instead. What is so confusing?

 

[Wanna-Be Sys Admin]

The offered solution was simply wrong,

It's not "wrong". The OP asked how they could work with their current
env solution. _I_ didn't suggest/recommend they use env. It's been
covered why it's not preferable. I gave them the appropriate response
to inform them how they can still enable warnings with their current
method, if they really want to or must somehow use it.

so what Tad wrote is perfectly
valid.

Not really.

The right solution is to add the "nonstandard" location to
$PATH, so that env can find perl there.

I would agree that's a better solution, assuming their script will be
able to use $PATH. They didn't say how many different ways they'll be
running the script. It might be CGI and CLI, so env might be a better
solution than modifying $PATH.

The problem has nothing to do with "-w" at all!!!

Actually, it did. The OP's question was how to pass -w to the script.
My response simply said that "if that's how you want to run it", to
then just use warnings; instead.

Bye...

Dirk

Cya.

 

[Wanna-Be Sys Admin]

Anyway, I stated it they

^^

*if

 

[Wanna-Be Sys Admin]

Dirk Heinrichs wrote: [re: #!/usr/bin/env perl -w]

The right solution is to add the "nonstandard" location to
$PATH, so that env can find perl there.

I would agree that's a better solution, assuming their script will be
able to use $PATH. They didn't say how many different ways they'll
be
running the script. It might be CGI and CLI, so env might be a
better solution than modifying $PATH.

It's not a 'better' solution. The OP was already assuming his desired
perl was in th PATH.

Ben

Better for shell, if you know it won't change. Doubtful PATH or env are
"better".

 

[Xho Jingleheimerschmidt]

If I use my specific perl path, it will not be portable, right?

Portable to what? Some machines don't even *have* a /usr/bin/env, so
using that surely is not portable. And what if the machine to which you
are porting does have /usr/bin/env, but also already has perl scripts
using /usr/bin/env to run their non-standard-location perl, which is
different than the porting-from machine's non-standard perl? How do you
have two different non-standard perls both appearing first in the path?

If you want to improve portability, then come up with a standard perl
version to use, and a standard place to install it, and then stick with
your standard. Anything else is just playing whack-a-mole.

After
all, if it moves to a different machine, the path has to be fixed.

Too bad there isn't a language that makes it easy to change the first
line of a large set of files...

Xho

 

[Xho Jingleheimerschmidt]

(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

 

[Ilya Zakharevich]

I think you've lost that one. 5.005 is dead dead dead, as it should be.
Many (most?) people already consider 5.6 to be unsupportable.

I'm still getting (though, an extremely sparse) trickle of bug reports
for 5.005...

[1] Well, *I* can change it because I'm sysadmin on most of the systems
where my code runs. But that's far from universal.

But PERLLIB *is* universal.

But not easy to use correctly.

True. For me, it is very sad that 15 years after the architecture of
modules was born, there is still no framework to make it *easy*. IMO,
the following components should be present:

a) A writer of module should be able to replace the file INSTALL by
a link to a piece of "standard documentation" which describes
WELL the simplest ramifications of the process of an install of a
distribution (say, for distributions based on Makefile.PL).

There should be at least two entry points: one for distributions
with scripts, one for those without scripts. But they should
cover ALL aspects: root access or not, setting up PATH and
PERLLIB on tcsh/Bourne/Windows/Mac (maybe even setting up DLL
path for distributions needing external libraries), setting up
CPAN.pm configuration.

b) But this is not enough. Some grandmothers just can't read even
well written technical documents of non-0 level of complexity.
For these situations, there should be an automatic tool (as in
cpan -autosetup
) which RECOGNIZES itself all the situations mentioned in "a",
and makes the needed 4-5 edits in user configuration itself. The
user feedup should be minimal:

To auto-setup the module installation for your personal access:

I will change this line to that your file FOO (backup of the
file will be saved in BAR). Etc etc Etc

Press Y if you agree to these changes. Press any other key
to stop auto-setup without any change to your current configuration.

or it should bulk out when e.g., the syntax of a line in .tcshrc
which sets PATH is too complicated to parse.

More importantly, messing around with third-party modules is a bad idea
unless you're planning to fork the distribution, which is a fairly major
step. None of the other modules you have installed will have been tested
against your patched version, and as soon as you upgrade you'll either
lose your changes or have a tricky merge on your hands.

I do not buy this (at least not at the list price ;-). When you
install a new version of a module, do you check that this update did
not break all the other installed modules? Until we do this, having a
local install is not THAT MUCH worse.

(But I know what you mean here too. My local CPAN.pm on one system
got obsoleted even with snail-speed of updates of Solaris, and I
needed some time to debug this... Can one design simple-to-use
tools to avoid this? Like part of PERL5LIB marked as
MUST_NOT_CONTAIN_OLDER_VERSION_THAN_REST_OF_PERL5LIB
)

Yours,
Ilya

 

[Ilya Zakharevich]

[2] I remember the bad old days of C programming where you could choose
between getting lots of warnings from system header files and turning
off many useful warnings.

This is not my experience with using -w. At least not for a decade.

This will be because most modules 'use warnings', and 'no warnings'
where they need to, which overrides -w.

I call this BS:

.cpan\build>pfind . "/\.pm$/" "=~ /\b use \s+ warnings \b/x" du

9192861 bytes in 932 files, 0 directories

.cpan\build>pfind . "/\.pm$/" du

89051284 bytes in 4312 files, 0 directories

The numbers are duplicated due to ./blib/*, but it does not change
the ratio (which is 10% in metric of byte-of-code ;-).

Yours,
Ilya

 

[Ilya Zakharevich]

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.

Did I argue with this? All I did was adding that

in my 20 year observing people (most with top-level minds) using
computers, I saw much more cases when the script "won't run", and a
person in question would have no clue how to fix it.

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.

But think about it the other way: if installing scripts were easier
than it is with hard-coded directories, maybe they would? 1/4 ;-)

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.

So they do it by using #!/bin/env perl (no smiley!). (E.g., this may be
more robust than having an install script to delete itself on completion...)

Ilya

 

[Ilya Zakharevich]

Nope. I never said this was for /usr/bin. The symlink would (or
should) be from their user's account path, and point that to wherever,
if they were going to use a symlink. This would allow them to run it
on whatever system, and just have to point the one symlink to the
system's Perl install.

Won't work. Here, /home directories migrate between different mount
points...

Hope this helps,
Ilya

 

[Wanna-Be Sys Admin]

Won't work. Here, /home directories migrate between different mount
points...

Hope this helps,
Ilya

Would it matter what home directory the account had, if they created
symlink to the unique path, or are you saying the mount points
alternate without notice and the path might change and break after the
initial link creation? Anyway, I suppose a few of the solutions have
got'yas.

 

[Ilya Zakharevich]

Would it matter what home directory the account had, if they created
symlink to the unique path, or are you saying the mount points
alternate without notice and the path might change and break after the
initial link creation?

When I "invented" your proposed solution, I investigated why it does
not work. There were several reasons; what I remember:

a) when entering from different computers on the net, $HOME may
point to different locations (via local disk, or via NFS mount
points - which in turn may be mounted differently on different
architectures);

b) when a disk carrying (a bunch of $HOME directories) would fill
up, $HOME may migrate to a different disk on a different computer.

I do not think "prior notice" matters - should I hunt for all
symlinks which are going to be broken? And *when* I'm going to
do this? AND: I do not remember any notice anyway...

Yours,
Ilya