in reply to Running with warnings on a remote server

The suggestions here are all well and good, but IMO the correct way is to develop the script on a local server, taking note of the various warnings that appear in regular operation, and either eliminating their cause (like mentioning variables in void context to get rid of only used once warnings) or selectively placing { no warnings 'whichever_warning_type_crops_up'; '...'; } (or for older versions, { local $^W = 0; '...'; } ) blocks around any code you know to cause warnings during regular operation.

Bottom line, unless the script dies horribly, running it should never produce warnings. (This is in fact a rule I stick to even outside of CGI scripts - the only time I disregard it is in throw-away scripts written for a single task at hand.)

Replies are listed 'Best First'.
Re: Re: Running with warnings on a remote server
by Elliott (Pilgrim) on Nov 05, 2001 at 13:22 UTC
    It's all very well saying that the correct way to develop the script is on a local server - if you have one. If I had one, I wouldn't have the problem in the first place!

    I hope everyone who turns on the warnings flag does it in order to clean up their code rather than for the entertainment of their users!

    Thanks everyone for the information - excellent and detailed as usual. Praise be! For the Monks are great!

      Never fear, CGI is here! :-) That is, unless you're trying to write stuff that fiddles with stuff tied to a server (mod_perl handlers for certain request phases f.ex). If you're just writing a plain ol' CGI script, its debug mode should be of great help, letting you run CGI scripts as if they were regular ones. Of course, it's more tiresome to debug them this way, as opposed to clicking refresh on your browser..