Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Debugging CGI/PERL

by Trihedralguy (Pilgrim)
on Mar 21, 2007 at 15:07 UTC ( #605856=perlquestion: print w/ replies, xml ) Need Help??
Trihedralguy has asked for the wisdom of the Perl Monks concerning the following question:

I have a quick question regarding CGI/PERL and the best way to debug past if statements
Usually if I have problems I will run the program in unix, and it will tell me things like "Error on line 56" or something like that..But once you start developing CGI/PERL with if statements and different pages, so my question is, how can i figure out where an error is occurring, if in unix I cant completely process the script.

Comment on Debugging CGI/PERL
Re: Debugging CGI/PERL
by sgifford (Prior) on Mar 21, 2007 at 15:18 UTC
    A few ideas:
    • 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
Re: Debugging CGI/PERL
by thezip (Vicar) on Mar 21, 2007 at 15:48 UTC

    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.


    Where do you want *them* to go today?
Re: Debugging CGI/PERL
by punch_card_don (Curate) on Mar 21, 2007 at 15:52 UTC
    If you mean that the script will run up to apoint, but then fails - in that case you can insert "print" statements to output to the browser where you are so far.
    if ($case_1) { print "<p>made it into case 1 and var_x = $var_x\n"; ...rest of IF..... }
    and so on...



    Forget that fear of gravity,
    Get a little savagery in your life.
Re: Debugging CGI/PERL
by Bro. Doug (Monk) on Mar 21, 2007 at 16:11 UTC
    The CGI::Carp idea is good. If you don't want to output errors to your web pages, just use Carp; (croak ~ die, carp ~ warn ) to get stacktraces output to the error logs.

    Also, the error logs may be in a few places, depending on the system you're working on. Look in /etc/httpd/logs/ or /var/log/httpd. If you think there's something more going on, try:
    %> cat /etc/httpd/conf*/*.conf | grep -i Log
    You'll get a list of all the mentions of logging in the conf and conf.d files.

    Also, when you check code with perl -c, put in all the options you would normally put on the #! line. For example, you may want to use:
    %> perl -cwT some.cgi


    And lastly, use __FILE__ and __LINE__ if you're having trouble inside of if statements. These always work (in my experience... nothing really -always- works).
    if( 1 ){ &foo || die "$! at " . __FILE__ . "-" . __LINE__ ; }


    I hope this helps. Good luck!
    Bro. Doug :wq
Re: Debugging CGI/PERL
by Trihedralguy (Pilgrim) on Mar 21, 2007 at 16:19 UTC
    My errors are happening within IF statements - and they are compile time errors - I guess thats how you describe them. Anyway, I dont understand what i do with the _FILE_ example.
      __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.

      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

Re: Debugging CGI/PERL
by talexb (Canon) on Mar 21, 2007 at 16:39 UTC

    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?").

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Debugging CGI/PERL
by osunderdog (Deacon) on Mar 21, 2007 at 16:56 UTC

    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/;

    Then run the cgi through perl using the debugger settings:

    perl -d mycgi.pl

    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

    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;
    lines scattered through the code that you want to debug.

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

    Hazah! I'm Employed!

      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.

Re: Debugging CGI/PERL
by Trihedralguy (Pilgrim) on Mar 21, 2007 at 18:57 UTC
    Ive narrowed my error down thanks to all of these comments...Apparently its something to do with "Premature end of script headers" whatever that means. I will have to investigate that.
      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...
        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');

        __________
        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.

Re: Debugging CGI/PERL
by Gilimanjaro (Hermit) on Mar 26, 2007 at 12:45 UTC

    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).

Re: Debugging CGI/PERL
by Trihedralguy (Pilgrim) on Mar 26, 2007 at 23:29 UTC
    My problem was my own stupidness...I had an extra "; inside of a DBH/DBI connection and that just messed everything up. I figured as much I should post a solution to what my problem was, just case someone needed this assistance.
Re: Debugging CGI/PERL
by SimonClinch (Chaplain) on Apr 21, 2011 at 12:50 UTC
    It is possible to run CGI scripts through the debugger (perl -d) - I can't remember what I did the last time to make that work throughout the script, but cgi methods simply output html to STDOUT instead of the browser if you do that. A bit of tweaking of values using the debugger may be needed to fake input from the user and the browser environment in most cases. Or in worst cases, you can create an override package called DEBUGCGI that inherits from CGI and overrides methods and tweaks values as necessary and use that instead.

    One world, one people

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://605856]
Approved by kyle
Front-paged by derby
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (9)
As of 2014-07-30 19:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (239 votes), past polls