• Look in your Web server logs. That's where these errors will show up.
• CGI::Carp will make errors show up in your browser, but generally not compile-time errors.
• If you can't get to your Web server logs, try wrapping your CGI script in a small wrapper that will send errors to the browser. For example, if your CGI program is called dosomething, name this shell script dosomething-debug, make it executable, then run this script from your browser to see errors.

  #!/bin/sh -e
  
  exec 2>&1
  printf "Content-type: text/plain\n\n"
  echo "Current directory:"
  pwd
  exec /path/to/dosomething
  [download]

  
  --
  sgifford's Web page

Before deploying, you should have also run `perl -c <scriptname>` in a shell for each script.

The "-c" compiles the script, informing you of lines that have errors.

%> cat /etc/httpd/conf*/*.conf | grep -i Log
[download]

%> perl -cwT some.cgi
[download]

if( 1 ){ 
 &foo || die "$! at " . __FILE__ . "-" . __LINE__ ;
}
[download]

I highly recommend Log::Log4perl for debugging -- you can set the messages to DEBUG during development, then wind it back to WARN for Production.

If you start to see a problem, you can turn the logging level back to DEBUG -- without touching the code -- to identify the problem. This is a lot nicer than print statements in the CGI, because you can diagnose the problem in Production code without the customer knowing ("Hey, how come I have all these comments in my web page?").

I've been here, and it's sometimes difficult. However you should try the -debug option available on the CGI pacakges... Of course I'm assuming you're using that.

Use the following use statement to enable debugging:

use CGI qw/:standard -debug/;
[download]

Then run the cgi through perl using the debugger settings:

perl -d mycgi.pl
[download]

Then you will have to pass cgi parameters. As value pairs. The perldoc for CGI goes into this -- search for 'debugging'.

Also, if there's a point in the flow that you come back to for debugging, you could write out the CGI context to a file . Then subsequently read that context back in to bring you back to a point where you want to debug. restore_parameters is documented in the perldoc.

Finally, and this one takes a little work, but you could possibly force the perl/tk debugger to come up. First you would have to start out your cgi with the following shebang:

#! perl -d:ptkdb
[download]

HOWEVER. For this to work you would have to allow any xwindow display to open on your desktop. And you would have to have the DISPLAY environment variable set for apache or by apache before the CGI is invoked... It's hard to setup, but it would give you the best debug situation you could imagine.

It would also help if you had a few

$DB::single=1;
[download]

Just a few thoughts that might get you where you want to be.

For debugging with ptkdb you can put the setting of DISPLAY in a BEGIN block:

BEGIN { $ENV{DISPLAY} = '192.168.32.50:0' }

since ptkdb doesn't try to display a window until after compilation is complete.

if ($case_1) {
     print "<p>made it into case 1 and var_x = $var_x\n";
     ...rest of IF.....
}
[download]

I don't understand how adding "if" statements to a program makes it harder to debug. Perhaps you could give a (short) example.

And if you told us which compile time errors that you're getting then we might be able to help you fix them.

Have you tried adding "use diagnostics" to your code?

--


See the Copyright notice on my home node.

"The first rule of Perl club is you do not talk about Perl club." -- Chip Salzenberg

__FILE__ and __LINE__ are special perl variables that give the file name and line number, respectively. You can also try caller(), but I'm not sure how that behaves inside an IF.

Bro. Doug :wq

You can also try caller(), but I'm not sure how that behaves inside an IF.

It works the same way it does anywhere else; nothing if does intrinsically changes the call stack.

It means that the output is not well formed. This can either be: i) you made a mistake in the response header, which needs to start with Content-type: text/html and two line breaks (but proper usage of any CGI module will take care of that); ii) something is erroneously printed into your response before this header (a debug print for example).

I'm nitpicking I know, but the response header can start and end with many directives...the only absolutely required one is Content-Type (and it must indeed end with two linebreaks). For example, this is perfectly legal:

Set-Cookie: USER_COOKIE=blahblahblah; path=/; domain=.example.com
Content-Type: text/plain
Transfer-Encoding: chunked
Content-Encoding: gzip

This is my content...
[download]

Of course, if the OP is already using CGI (which he should be), then you can simply use the CGI->header() method:

print CGI->header('text/plain');
[download]

__________
Systems development is like banging your head against a wall...
It's usually very painful, but if you're persistent, you'll get through it.

I like to use CGI::Debug for my CGI debugging...

It can log error, or even mail them to you (useful for when your CGI's hit production).