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

I am writing some CGI scripts to use with IIS 6.0 ... This version of IIS doesn't appear to have any error logging system that displays the output of perl's warnings or dies.

So, my question is, is there a way to write to file on warnings and die? I tried something like this: 
open(FILE,">>",$dieFile);
my $value = somecommand or die FILE "$!\n";
close(FILE);

[download]

but that doesn't seem to do it.

Replies are listed 'Best First'.
Re: Perl, Die, and IIS
by ikegami (Patriarch) on Nov 14, 2005 at 19:25 UTC

    You could write your own version of die: 

    sub my_die {
   open(my $fh, ">>", $dieFile);
   print $fh @_;
   exit(2); # or die("\n");  # or die(@_);
}

my $value = somecommand or my_die "$!\n";

    [download]

    Alternatively, you could try hooking $SIG{'__DIE__'}. It's documented in perlvar, under %SIG.

[reply]
[d/l]
[select]

      Don’t use stuff like my_die, which will not be respected by loaded modules. Don’t roll your own die handler.

      Do use CGI::Carp. In development, the easiest thing to do is use CGI::Carp qw( fatalsToBrowser );. Once you are in production on an errorlog-challenged server, you do what the module’s POD says:

      BEGIN {
    use CGI::Carp qw( carpout );
    my $logfile = '/path/to/cgi-name.log';
    open my $logfh, '>>', $logfile
        or die "Unable to open $logfile: $!\n";
    carpout $logfh;
}

      [download]

      Makeshifts last the longest.

[reply]
[d/l]
[select]
Re: Perl, Die, and IIS
by Animator (Hermit) on Nov 14, 2005 at 19:29 UTC

    Two comments:

    • it might do what you want if you use open (STDERR ">>", $dieFile);
    • Perhaps you should take a look at CGI::Carp? It has an option to redirect errors/warnings to a file...

    Update: added link

[reply]
[d/l]
Re: Perl, Die, and IIS
by ptum (Priest) on Nov 14, 2005 at 19:44 UTC
    I never write a CGI script that doesn't include this line: use CGI::Carp qw(fatalsToBrowser); It has saved my bacon many a time. :)
[reply]
      use CGI::Carp qw(fatalsToBrowser); should be removed from any production web page else you may inadvertantly give out too much information to potential attackers.

      Jason L. Froebe

      Team Sybase member

      No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

[reply]

      Quoting merlyn’s Computing Securely article:

      Don’t be too chatty in error messages

      Certainly, the user wants to know when something breaks, but usually the user seeing the error message isn’t the person who has to fix the code. They don’t need to know the precise SQL that triggered the error, or the name of the database being accessed, and so on, because that stuff is all very useful information to a bad guy.

      The most frequent violation I see of this principle is when use CGI::Carp qw(fatalsToBrowser) is left enabled on production code. This is wrong, very wrong. The random user at the other end of the HTTP connection needs only to be told that “something went wrong” and “we’re looking in to it,” and maybe a unique timestamp so they can report the error. Everything else that would have printed should be captured in an error log somewhere, not sent to the user for exploit.

      Make sure you read the rest of the article as well if this is news to you.

      Makeshifts last the longest.

[reply]
[d/l]
      There's also a large amount of discussion on this subject in Does fatalsToBrowser give too much information to a cracker?.

      --

      Oh Lord, won’t you burn me a Knoppix CD ?
      My friends all rate Windows, I must disagree.
      Your powers of persuasion will set them all free,
      So oh Lord, won’t you burn me a Knoppix CD ?
      (Missquoting Janis Joplin)

[reply]

Back to Seekers of Perl Wisdom