Error: Can't use global $^W in "my"

[Likeless]

Dear Monks,

I am intermittently receiving these errors on my production web server (Apache):

[Fri Apr 30 15:17:31 2004] [error] Can't use global $^W in "my" at /usr/www/httpd/cgi-bin/script.cgi line 1, near "{$^W "

It happens about three times a day, and on many different scripts. All the scripts are running under mod_perl, and I have not used the $^W variable explicitly in any of them (in fact, I didn't know what it was until I got these errors).

Most of my scripts start something like this:

#!/usr/bin/perl -w

BEGIN {
    unshift(@INC, "./modules");
};

use strict;

If it helps at all, some details of my system are:

Red Hat Linux 9.0
Perl 5.8.0
Apache/1.3.28 mod_gzip/1.3.26.1a
mod_ssl/2.8.15
OpenSSL/0.9.7a
mod_perl/1.28

mod_perl entry in httpd.conf:

        SetHandler perl-script
        PerlHandler Apache::Registry
        PerlModule Apache::DBI 
        PerlSendHeader On
       PerlRequire /usr/www/httpd/cgi-bin/modperl/startup.pl
        Options +ExecCGI

I hope you can help. Thanks in advance!

[bmann]

Here's what perl sees with the -w switch on the shebang:

$ perl -MO=Deparse
#!perl -w
^D
BEGIN { $^W = 1; }
- syntax OK

use warnings; instead of -w will stop the warnings since you're using a recent perl.

[perrin]

This probably has something to do with Apache::Registry and how it tries to handle the -w flag for you even though it's essentially too late for it. We could debug it with you on the mod_perl list if you can give us a sample script that causes it. However, as others pointed out, switching to "use warnings" will make it go away.

[dsb]

You cannot use my to declare any of the magical built-in variables Perl has.

If you want to modify the value of a built in, you must use local to do it, and then the modification will be local to the enclosing code block.

Update: Time to revisit local :)

[calin]

If you want to modify the value of a built in, you must you local to do it, and then the modification will be local to the enclosing code block.

A better approach, which doesn't suffer from the problems of dynamic scoping with local, would be to use the lexically scoped (no) warnings pragma instead for this particular situation - see perllexwarn