in reply to #!/usr/bin/perl -w

They never complain because Windows doesnt do shebang file type association. Instead it uses the file extension and the registry. The only part that is relevent is the "-w" part which turns on warnings.

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]
instead.

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.

Replies are listed 'Best First'.
... powerful?
by simeon2000 (Monk) on Jul 18, 2002 at 19:43 UTC
    Just curious, but how exactly is "use warnings;" more powerful than perl -w?
[reply]
      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.

[reply]
[d/l]
[select]

      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
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom