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;
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. | [reply] [d/l] [select] |
|
Just curious, but how exactly is "use warnings;" more powerful than perl -w?
| [reply] |
|
{
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] |
|
| [reply] [d/l] [select] |
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
--
just,my${.02} | [reply] [d/l] [select] |
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. | [reply] [d/l] [select] |
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:
#!perl
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.
| [reply] [d/l] [select] |
|
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.
| [reply] |
Re: #!/usr/bin/perl -w
by S_Shrum (Pilgrim) on Jul 18, 2002 at 22:00 UTC
|
| [reply] |
Re: #!/usr/bin/perl -w
by BrowserUk (Patriarch) on Jul 18, 2002 at 19:29 UTC
|
| [reply] |
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.
| [reply] |
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.
--twerq | [reply] |
Re: #!/usr/bin/perl -w
by Anonymous Monk on Jul 18, 2002 at 19:28 UTC
|
Thanks guys!
Definitely learning alot here.
| [reply] |
(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 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".
- tye (but my friends call me "Tye")
| [reply] |