Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

#!/usr/bin/perl -w

by Anonymous Monk
on Jul 18, 2002 at 19:01 UTC ( #182980=perlquestion: print w/replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

folks! what does:
#!/usr/bin/perl -w

do on my windows box?

i guess be starting my scripts with:
#!c:\Perl\bin\perl.exe -w

but the scripts that i copy down from this site and run on my windows box never comlpain about it. are the warnings switched on? does perl magically know how to handle it?


Replies are listed 'Best First'.
Re: #!/usr/bin/perl -w
by demerphq (Chancellor) on Jul 18, 2002 at 19:11 UTC
    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;

    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.


    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 ;

          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
Re: #!/usr/bin/perl -w
by thelenm (Vicar) on Jul 18, 2002 at 19:07 UTC
    perlrun gives some more information about how the #! line is processed. perl checks this line for switches whenever it runs, so under any OS, a shebang line that says
    #!/foo/bar/baz/perl -w
    should turn warnings on.

    -- Mike


Re: #!/usr/bin/perl -w
by FoncÚ (Scribe) on Jul 18, 2002 at 19:22 UTC
    If you use #!c:\Perl\bin\perl.exe -w as your shebang line, you may very well get errors when running CGI under a webserver, at least, I've found it to do that from time to time.

    You'll find that (to my knowledge) all Windows boxes run perl the same regardless of where you point the shebang line, but with a few different compilers (like ActivePerl), it will take the -w to give you warnings. If that doesn't work, you should utilize the use warnings; line.

    Hope that helps.
Re: #!/usr/bin/perl -w
by thunders (Priest) on Jul 18, 2002 at 19:46 UTC

    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:


    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.
Re: #!/usr/bin/perl -w
by S_Shrum (Pilgrim) on Jul 18, 2002 at 22:00 UTC
Re: #!/usr/bin/perl -w
by BrowserUk (Pope) on Jul 18, 2002 at 19:29 UTC

    For a little more info on this see this.

Re: #!/usr/bin/perl -w
by twerq (Deacon) on Jul 18, 2002 at 19:13 UTC
    With Windows, Activestate and the magic of file associations, your #! line may not be doing anything at all.

    Check into use warnings instead.

Re: #!/usr/bin/perl -w
by Anonymous Monk on Jul 18, 2002 at 21:34 UTC
    If you do not need the shebang line, chances are that perl is included within the System Path (right click on "My Computer" > "Advanced" > "Environment Variables" and then see the Path information. Chances are that the ActiveState installer created the path entry for you. So the guy who said that the program is in the registry is correct. Having the perl.exe in your System Path allows you to execute "pl", "cgi" or whatever mapped extensions that are perl programs. At least that is how I understand it. If I am mistaken, I would be more than happy to be corrected.
Re: #!/usr/bin/perl -w
by Anonymous Monk on Jul 18, 2002 at 19:28 UTC
    Thanks guys!
    Definitely learning alot here.
(tye)Re: #!/usr/bin/perl -w
by tye (Sage) on Jul 19, 2002 at 23:07 UTC

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

            - tye (but my friends call me "Tye")

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://182980]
Front-paged by lemming
[Discipulus]: I hope at least a minimal implementation, in the middle of july i'll have the first introductional course..
Discipulus nemo profeta in patria..

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (4)
As of 2017-06-27 09:18 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (601 votes). Check out past polls.