My bet is that you are using a relatively recent version of perl (probably an Activestate build) and accordingly you can lose that as well and use the more powerful

use warnings;
[download]

Incidentlly its sort of good form when posting to include a shebang line that should work on most standard *NIX boxes. #!/usr/bin/perl If only to make our *NIX brethren's lives a bit easier... Although i have to admit I usually dont out of forgetfulness.

Oh yeah, its possible that if you are doing CGI stuff that the webserver does know about shebangs, in which case it probably makes sense to include it.

HTH

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

Just curious, but how exactly is "use warnings;" more powerful than perl -w?

In short because it is all or nothing. It is a global flag and thus enables wanrings in modules you didnt write (which may have been written deliberately without warnings enabled for some reason.) Also because use warnings enables you to selectively enable or disable warnings for various types of problem as well as for the individual modules you are using (assuming that they have been written with warnings::register and its functions). Not only that you can selectively make certain types of warning fatal, enabling you have your code die if certain types occur.

In long heres a copy of the section "Whats wrong with -w and $^W" from perllexwarn

---

What's wrong with -w and $^W

Although very useful, the big problem with using -w on the command line to enable warnings is that it is all or nothing. Take the typical scenario when you are writing a Perl program. Parts of the code you will write yourself, but it's very likely that you will make use of pre-written Perl modules. If you use the -w flag in this case, you end up enabling warnings in pieces of code that you haven't written.

Similarly, using $^W to either disable or enable blocks of code is fundamentally flawed. For a start, say you want to disable warnings in a block of code. You might expect this to be enough to do the trick:

     {
         local ($^W) = 0 ;
         my $a =+ 2 ;
         my $b ; chop $b ;
     }

When this code is run with the -w flag, a warning will be produced for the $a line -- "Reversed += operator".

The problem is that Perl has both compile-time and run-time warnings. To disable compile-time warnings you need to rewrite the code like this:

     {
         BEGIN { $^W = 0 }
         my $a =+ 2 ;
         my $b ; chop $b ;
     }

The other big problem with $^W is the way you can inadvertently change the warning setting in unexpected places in your code. For example, when the code below is run (without the -w flag), the second call to doit will trip a "Use of uninitialized value" warning, whereas the first will not.

    sub doit
    {
        my $b ; chop $b ;
    }

    doit() ;

    {
        local ($^W) = 1 ;
        doit()
    }

This is a side-effect of $^W being dynamically scoped.

Lexical warnings get around these limitations by allowing finer control over where warnings can or can't be tripped.

---

Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.

For one, use warnings gives you more control over the warnings you receive. See perldoc warnings for more info.


_______________
D a m n D i r t y A p e
Home Node | Email

#!/foo/bar/baz/perl -w
[download]

-- Mike

--
just,my${.02}

for most Windows perl applications (console, GUI) this is not necessary. But if you use apache as a local webserver you need a she bang unless you edit your http.conf file to recognize .pl.

In general, at least with an active state install your perl is placed on the path. so:

#!perl
[download]

is enough to call your interpreter. #!/usr/bin/perl will cause a 500 server error on Apache for windows. So if you test CGI's at home on windows and deploy to a UNIX server, it's something that you need to deal with.

yeah ... you don't realy need any path at the begginnig of perl script under windows (activestate perl)... if your file name is *.pl windows uses assoaciations that alow to forget about the path to perl interpreter.

I had the same issue. Lucky I got a answer for ya.

Look at this: How do I...Fool Windows into using *nix formatted shebang

======================
Sean Shrum
http://www.shrum.net

For a little more info on this see this.

FYI, I use "#!/usr/bin/perl -w" even on Windows. I like to have Perl scripts that you can simply copy to a new system and have them work without modifications. So I also consider a system that has Perl but doesn't have a /usr/bin/perl to be broken (I make an exception for Win32 systems if they are not using Perl for CGI under Apache).

I also usually use "-w" even though "use warnings" is finally getting old enough that I'm surprised when I find a version of Perl that doesn't have warnings.pm. Why?

Well, first, I don't really recommend enabling any warnings in "production" situations unless you've done the work to get the warnings delivered to the people writing the code instead of to the people trying to use the code. Many warnings are run-time and can be triggered in production even though they were never triggered during development and testing. They can even become a serious nuisance out of the blue.

So, if you haven't done the work to reroute warnings to developers, then I recommend "#!/usr/bin/perl -X" in production environments as this disables all warnings, even in code that has declared "use warnings".

And I strongly recommend enabling warnings during development and testing. So much so that I think you should at least occasionally test with "-W" so that you see warnings even for modules (or other scopes) that have declared "no warnings". It can be educational.

So I always start out with "#!/usr/bin/perl -w" so I can see warnings in any modules where the author hasn't declared "I know this gives warnings but they don't seem important" (by using "no warnings"). If that gets me warnings in some module that I can't be bothered to investigate further, then I might switch from "-w" to "use warnings".