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

[Peng Yu]

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

 

[Ilya Zakharevich]

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

Your (Unix) kernel cannot handle more than one argument. A known
limitation. You need to set the effect -w "by hand":

#!/usr/bin/env perl
BEGIN { $^W = 1 } # Can't use -w `with env perl'

Yours,
Ilya

 

[Peter J. Holzer]

Since my perl is installed in a nonstandard location, I have to use '/
usr/bin/env perl'. [...]
#!/usr/bin/env perl -w

No. You should use

#!/path/to/your/perl -w

instead.

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

This is because the syntax for the shebang line is extremely restrictive
on most unixes. In this case (Linux?) everything after the first space
is passed to /usr/bin/env as a single argument. There may be a
workaround but The Right Thing(TM) is to use the correct path to perl in
the first place.

hp

 

[Randal L. Schwartz]

Peng> Since my perl is installed in a nonstandard location, I have to use '/
Peng> usr/bin/env perl'. I also what to use it with '-w'. I'm wondering how
Peng> to do it.

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.

 

[Peng Yu]

Peng> Since my perl is installed in a nonstandard location, I have to use'/
Peng> usr/bin/env perl'. I also what to use it with '-w'. I'm wondering how
Peng> to do it.

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.

If I use my specific perl path, it will not be portable, right? After
all, if it moves to a different machine, the path has to be fixed.

 

[l v]

If I use my specific perl path, it will not be portable, right? After
all, if it moves to a different machine, the path has to be fixed.

Create a symbolic link for /usr/bin/perl to your non-standard location
and you should then be able to use the correct shebang in your Perl scripts.

 

[Kevin Collins]

Create a symbolic link for /usr/bin/perl to your non-standard location
and you should then be able to use the correct shebang in your Perl scripts.

This assumes you have rights to do that, which is often not the case...

In a similar situation with one of my clients, where I have access only as a
"user" not an "admin" I wrote a ksh wrapper script (perlwrap) that does various
techniques to identify the "correct" perl (based on OS version and
architecture), and then:

exec /path/to/perl "$@"

Then, in my scripts I have:

#!/mypath/perlwrap -w

Of course, that assumes you can store the wrapper script in a fixed path...

Kevin

 

[Wanna-Be Sys Admin]

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.

 

[Wanna-Be Sys Admin]

This assumes you have rights to do that, which is often not the
case...

The Op's first post shows they have shell access, and I find that
assumption curious, as I've never seen a system prevent a user from
creating symbolic links (even if it did, it would be unlikely a system
could prevent the user from executing the ln binary they could upload
themselves, even if tehy didn't have access to the compilers). But, I
suppose it's possible. I just think they should call use warnings; at
the top and not have to mess with anything else, though I never, ever
use env in a script myself.

 

[Dirk Heinrichs]

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.

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

Bye...

Dirk

 

[Dirk Heinrichs]

#!/usr/bin/env perl
BEGIN { $^W = 1 } # Can't use -w `with env perl'

Yes, you can!

Bye...

Dirk

 

[Dirk Heinrichs]

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.

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

Damn, forgot to switch on brain. No, one can not use '#!/usr/bin/env perl -
w'.

Sorry for the noise.

Bye...

Dirk

 

[Dirk Heinrichs]

Yes, you can!

Damn, I was so sure that I already did this in the past. You're right, it
doesn't work.

Bye...

Dirk

 

[Ilya Zakharevich]

The "warnings" pragma is preferred over the -w switch now anyway:

use warnings;

Wrong. `use warning' is useful in a module. It is mostly useless in
a script. One should always use -w in scripts.

Yours,
Ilya

 

[RedGrittyBrick]

Wrong. `use warning' is useful in a module. It is mostly useless in
a script. One should always use -w in scripts.

Can anyone provide a reference to where Ilya (or anyone else) provides
an explanation of this assertion?

It doesn't seem to be in accord with `perldoc perllexwarn`. Am I right
to assume there is some disagreement on this point?

 

[Dr.Ruud]

Ilya Zakharevich wrote:

Can anyone provide a reference to where Ilya (or anyone else) provides
an explanation of this assertion?

It doesn't seem to be in accord with `perldoc perllexwarn`. Am I right
to assume there is some disagreement on this point?

I prefer -w in scripts too, because it enforces warnings on the included
code.

The 'use warnings' is only lexical, that's all there is to it.

 

[Randal L. Schwartz]

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, so if you're using CPAN modules, you really
*don't* want warnings enabled on them, because you're not the author of that
code.

print "Just another Perl hacker,";

 

[John W. Krahn]

I prefer -w in scripts too, because it enforces warnings on the included
code.

Then you probably want to use -W instead of -w.



John

 

[Peter J. Holzer]

I prefer -w in scripts too, because it enforces warnings on the included
code.

Which is why I disagree with Ilya and you. -w is mostly useless in a
script and should never be used except maybe as a quick hack during
debugging.

The 'use warnings' is only lexical, that's all there is to it.

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

I do think it was a good thing that -w was invented before "use
warnings": It forced module maintainers to clean up their code.

hp

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

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

 

[Peter J. Holzer]

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