As for tye's solution, that's neat, although I think I prefer to use goto &strict::import - just in case a future version would start using caller.

Abigail

I still don't understand. Is there any case where strict merely produces a warning?

I was under the impression that strict's only effect was to cause the compilation phase to fail if it didn't like the code. Are you sure you are not confusing strict with warnings? Or did I miss something?

strict.pm has run-time as well as compile-time checks. For example, symbolic references can only be detected at run time.

I consider dereferencing a symbolic reference to be an indication of a pretty serious error (if you wrote and tested the code under 'use strict') that I'd want that flagged in production. I fully support turning off warnings in production (though I even more support keeping warnings turned on and providing a system for the warnings to get routed to the developers so they can be "fixed").

FWI, I can't think of any warnings that are controlled by strict.pm, but that doesn't mean there aren't any. (:

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

I still don't understand. Is there any case where strict merely produces a warning?

What I'm talking about is strict failing a program at run-time, and then dumping stuff in the logs, viz:

Global symbol "$foo" requires explicit package name at /home/user/www/test.pl line 10.

.. it's getting rid of that kind of stuff that I'm talking about (I don't think warnings makes any difference in that case?)

This is no reason to disable strictures, it is a reason to use CGI::Carp's carpout() or set_message() functions. Disabling strictures is a serious mistake especially on a production server where failing a stricture at runtime should be indicative of a critical bug. In such a case, you want strict to scream bloody murder and kill your script rather than the script being able to run on and silently throw sand into your machinery.

Makeshifts last the longest.

But if you get your script working on the stage server, before moving it to the production server your 'use strict' shouldn't add anything to your webserver logs. Unless I'm mistaken, which did happen once before.