theAcolyte has asked for the wisdom of the Perl Monks concerning the following question:

Ok, I've had CGI::Carp installed and been using it for quite some time. In fact I'm pretty sure it came with the Distro (5.6.1) but it has suddenly ceased to work in the way I am used to it working. For syntax errors, I am just getting the standard "Internal Server Error" message instead of hte more helpful CGI::Carp messags from calling it with "fatalsToBrowser" exported. This is on solaris2.8 /apache.

To make sure I'm not simply insane, I ran the same script under MacPerl and it output the HTML formatted page I expected from Carp.

When calling an error directly, like die "something here"; carp(fatalsToBrowser) works as I expect it to on the solaris box. Its warnings to browser also seems to work properly. The only thing that does not output to the browser is syntax errors.

I've tried it with just the toBrowser exported, with other .pm's included and without; with CGI::Carp in a BEGIN block and not. None of these things seem to make a difference.

Here's the code I'm using to test CGI::Carp's behavior: 

#!/usr/local/bin/perl -w
 
BEGIN {
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
}

#die "This is a fatal error";
$first = "Hello"; #This should produce a warning

print "Content-Type: text/html\n\n";
warningsToBrowser(1);

print "<HTML><BODY>";
print "Its a beautiful day in the neighborhood,";
print "a beautiful day in the neighborhood...<BR>";

# Add a syntax error.
if($second == "Hello") { print "How are ya\n"; }
print "</BODY></HTML>";

[download]
If i put in the closing curly (the syntax error) it executes properly (its in the code above) and sends the warnings I'd expect. If I remove the closing curlie I get a generic "Internal Server Error" on solaris, but under Macperl I get the following: 
# syntax error, near ")  print"
File 'Calvin:Cleanup At Startup:2852655'; Line 19
# Unmatched right bracket, at end of line
File 'Calvin:Cleanup At Startup:2852655'; Line 19
Content-type: text/html

<H1>Software error:</H1>
<CODE># Execution of Calvin:Cleanup At Startup:2852655 aborted due to 
+compilation errors.
<\/CODE>
<P>
Please send mail to this site's webmaster for help.
# [Thu May 22 01:36:50 2003] Calvin:Cleanup At Startup:2852655: # Exec
+ution of Calvin:Cleanup At Startup:2852655 aborted due to compilation
+ errors.

[download]
Which is what I'd expect from CGI::Carp.

So ... does anyone have ANY idea why CGI::Carp would misbehave this way? Its the most recent version (I tried reinsalling with perl -MCPAN -e 'shell', and eventually forced it to reinstall) and it seems to be functioning partially.

Finally, I also checked the normal error logs to see if CGI::Carps output was appering there; it was not.

Any help or adivce appreciated.

Erik

edit jeffa - escape inner closing code tag

Replies are listed 'Best First'.
(jeffa) Re: CGI::Carp Doesnt seem to work properly
by jeffa (Bishop) on May 22, 2003 at 07:49 UTC
    CGI::Carp is not a substitute for perl -c (or whatever the equivalent is for Win32).

    [that would be perl -c ... thanks Enlil ;) ]

    It is intended for redirecting warnings and run-time errors, but not syntax errors [ UPDATE - this is simply wrong ... CGI::Carp is intended to handle syntax/compile time errors. Looks like this may be a bug introduced in version 1.24. See below ] 
    use strict;
use warnings;

use CGI::Carp qw(fatalsToBrowser warningsToBrowser); 
warningsToBrowser(1);

if(my $foo == 'bar') { die "yes"; }

    [download]
    You could wrap the code in question in an eval block, but it's easier to test the syntax on a command line.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]

      Jeffa; While I dislike disagreeing, I've seen syntax errors in my browser window with CGI::Carp before - I'm 99.9% sure. That .1% of doubt comes from your comments. However, the documentation POD for CGI::Carp states:

      "Fatal errors will now be echoed to the browser as well as to the log. CGI::Carp arranges to send a minimal HTTP header to the browser so that even errors that occur in the early compile phase will be seen. Nonfatal errors will still be directed to the log file only (unless redirected with carpout). "

      So that would imply compile time (syntax) errors will show up from CGI::Carp.

      = Erik

[reply]
Re: CGI::Carp Doesnt seem to work properly
by submersible_toaster (Chaplain) on May 22, 2003 at 07:50 UTC

    I'm not speaking authorativly but won't apache return the internal server error because it can't compile and run the perl (because it has a syntax error) CGI::Carp is taking care of run-time errors not compile-time - right?

    Anticipating the shout down that follows :)


    I can't believe it's not psellchecked
[reply]
      All I know is CGI::Carp was returning compile time errors just a week or two ago; it saved me the trouble of having to open an extra window to peruse the error log while debugging. So, something changed, but I've *NO* idea what.
[reply]
Re: CGI::Carp Doesnt seem to work properly
by rinceWind (Monsignor) on May 22, 2003 at 16:13 UTC
    I've been round this loop several times, and here is a quick checklist.

    • Is the shebang (#!) line correctly formed and pointing to the correct directory for perl?
    • Does the program clean compile under perl -c (others have mentioned this, but it is inclded for completeness)
    • Does the WWW user have read and execute permissions on the script?
    • Is there something in a BEGIN block failing? (depending on the logic, this might not be picked up by perl -c)

    I suggest the following advice: sweet talk your sysadmin into giving you read permission on the Apache log. This may be only operative for a day, as many webserver boxes cycle the logs on a cron job.

    Try also running your script from the command line:

    perl myscript.cgi foo=1 bar=quux user=fred password=bloggs

    [download]
    CGI.pm picks up params off the command line if you use name=value pairs. You can also use -d to invoke the perl 5 debugger if you have a really tough problem.

    Hope this helps

    --rinceWind

[reply]
[d/l]
(jeffa) Re: CGI::Carp Doesnt seem to work properly
by jeffa (Bishop) on May 22, 2003 at 23:23 UTC
    After reading tye's comment i decided to do little searching. In one of the nodes in the thread he references, he points out that CGI::Carp V1.14 handles compile time errors just fine. I headed on over to Mr. Stein's backpan folder and started grabbing older versions, trying to see where CGI::Carp no longer handles compile time errors. It looks like Version 1.23 was the most recent version that doesn't have this bug ... and i am convinced it is a bug as the following script: 
    #!/usr/bin/perl

use CGI::Carp qw(fatalsToBrowser);
$i = 1 / 0;

    [download]
    did not produce an Internal Server Error, whereas CGI::Carp versions 1.24 and 1.25 do produce ISE's on my machine when that script is run. I diff'ed version 1.23 against 1.24, but i didn't see understand anything. ;)

    If you want to find CGI::Carp 1.23 right now, it is located in CGI.pm-2.81. I simply untar'ed the file and copied it's Carp.pm over the one currently installed. A bug ticket has been reported.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]

      I didn't know anything about bug tickets, but I had already emailed Mr. Stein; I thought I would make a note for anyone who reads this thread.

      I got an email back from the author noting he was already aware of the bug and that it would be fixed in the next release.

[reply]
Re: CGI::Carp Doesnt seem to work properly
by tye (Sage) on May 22, 2003 at 18:40 UTC

    You don't need that BEGIN block around your 'use' line.

    CGI::Carp certainly catches any compile-time errors that happen after the ; on the end of the 'use' statement for me. I've seen other people report this not being the case. Let me find that thread... use CGI::Carp qw(fatalsToBrowser);.

    I don't see a final explanation in that thread. Perhaps you'll get further in figuring out why it works for me but not for you two.

                    - tye
[reply]

Back to Seekers of Perl Wisdom