A start would be to just tell those of us who have never heard of it a bit about it.

PERROR(3)               Library functions               PERROR(3)



NAME
       perror - print a system error message

SYNOPSIS
       #include <stdio.h>

       void perror(const char *s);

       #include <errno.h>

       const char *sys_errlist[];
       int sys_nerr;

DESCRIPTION
       The  routine  perror()  produces a message on the standard
       error output, describing the last error encountered during
       a  call  to  a system or library function.  First (if s is
       not NULL and *s is not  NUL)  the  argument  string  s  is
       printed,  followed  by a colon and a blank.  Then the mes-
       sage and a new-line.

       To be of most use, the argument string should include  the
       name  of  the function that incurred the error.  The error
       number is taken from the external variable errno, which is
       set  when  errors occur but not cleared when non-erroneous
       calls are made.

       The global error list sys_errlist[] indexed by  errno  can
       be  used  to obtain the error message without the newline.
       The largest  message  number  provided  in  the  table  is
       sys_nerr -1.  Be careful when directly accessing this list
       because new error  values  may  not  have  been  added  to
       sys_errlist[].

       When  a  system call fails, it usually returns -1 and sets
       the variable errno to a value describing what went  wrong.
       (These  values  can  be found in <errno.h>.)  Many library
       functions do likewise.  The function  perror()  serves  to
       translate  this error code into human-readable form.  Note
       that errno is undefined after a successful  library  call:
       this  call  may  well change this variable, even though it
       succeeds, for example  because  it  internally  used  some
       other  library  function  that failed.  Thus, if a failing
       call is not immediately followed by a call to perror,  the
       value of errno should be saved.


CONFORMING TO
       ANSI C, BSD 4.3, POSIX, X/OPEN

SEE ALSO
       strerror(3)




                            2001-12-14                  PERROR(3)
[download]

And here's a way one might do it in Perl:

package PError;

use strict;
use warnings;

our ($VERSION) = q $Revision: 1.1 $ =~ /([\d.]+)/g;

sub perror {warn @_ ? "@_: $!\n" : "$!\n"}  
sub pdie   {die  @_ ? "@_: $!\n" : "$!\n"}

my %symbols = map {$_ => 1} qw /perror pdie/;
 
sub import {
    my $class  = shift;
    my $caller = caller;
 
    foreach my $name (@_ ? @_ : keys %symbols) {
        die "'$name' is not exported.\n" unless $symbols {$name};
        my $func = $name eq "pwarn" ? "perror" : $name;
        no strict 'refs';
        *{$caller . "::$name"} = \&{$class . "::$func"}
    }
}
 
 
1;
 
__END__
[download]

when files arent there its usually a serious matter and I want to be able to track it back from the line it died from.

Abigail

A line number in the program that figured out the file wasn't there doesn't do much for me.

Well, my logging system automatically graduates die into confess so i actually get a full back trace. And here at least usually the reason a file isnt there is becuase somebody told the program to operate on something that it shouldnt. :-) Rarely is it due to a failure on the upstream side.

BTW, the problem I have with something like what you describe here is that it wont be able to show the filename involved will it? At least not without overriding open.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

BTW, the problem I have with something like what you describe here is that it wont be able to show the filename involved will it?

Since about all pdie and perror do is tack "$!\n" to the die or warning message, I fail to agree.

    open my $fh => $file or pdie open => $file;
[download]

might print "open /ect/passwd: No such file or directory".

Abigail