Re: use CGI or die;

[ColonelPanic]

in reply to use CGI or die;

Another huge debugging benefit of CGI is CGI::Carp

use CGI::Carp qw(fatalsToBrowser);

This is invaluable for figuring out a CGI problem. Not only do you see errors, but you can easily insert your own die(); statements to see what's going on, instead of printing your own header and HTML in several lines.

[davorg]

But you don't need to be using CGI in order to make use of CGI::Carp.

--
<http://www.dave.org.uk>

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

[epoptai]

I always use strict, -w and fatalsToBrowser when developing, but today this caused me a huge headache in a simple script (with no syntax errors) that merely reads a file, formats the contents, and displays the html.

It runs fine from the command line (with a few uninitialized value warnings) and could save the output with

perl foo.pl > foo.html

but it would just whirl and give no output via CGI. I found that the code looks and behaves perfectly via CGI unless both -w and fatalsToBrowser are enabled! Shut either one off (leaving the other on) and it works fine.

I found a certain loop in the program that seems to cause this by throwing pairs of =cut around, but the loop seems mundane and similar to the others.

Is this odd interplay between -w and fatalsToBrowser documented?

Update: I said i'd node the entire script to craft in a day or two but am finding it difficult to abstract a simplified example. So i'll just suggest that if your error-free cgi script mysteriously hangs, turning off either -w or fatalsToBrowser may help.

dws - Try this for a good html ™:

™

[dws]

Show us the code!

Enquiring Monks Want to Know™