new module IO::Mail

Hi everybody,

This was the idea that I was working on with Mail::Preconfigured a while 
back.  The gist of it is that you can turn STDOUT and STDERR into 
messages that get mailed to you and even have it work with die().

The code is in my subversion repository, synopsis below for convenience.

Any thoughts about the interface are welcome.  Even more welcome would 
be suggestions about how to get DESTROY to work as documented in 
perldoc perlobj (at least AFAICT it is misbehaving (this is 5.8.4.))  
My original interface concept was to have the mail sent when DESTROY() 
got called, but the guts of my objects (some Mail::Message objects) 
seem to occasionally disappear before we get there.  I then considered 
using the CLOSE function for the tied filehandles as the send trigger, 
but the implicit close of handles at the end of the program doesn't 
seem to trigger that.  So, I've reverted to requiring that an explicit 
send() be called with the object (but the errors() constructor will 
install a sending sub into $SIG{__DIE__} (because otherwise the whole 
point of this thing is lost.))

One (slightly amusing) caveat to using the STDERR tie is that you get 
your warnings in the inbox (use $err->abort or something during 
testing.)  Yeah.  It needs more options (like to send mail via 
something besides SMTP, etc) but what it really needs is a good solid 
hook that happens just before the GC process.

Your comments and/or suggestions and feedback would be great.  If 
there's enough interest (and I figure out how to defuse the insanity) 
I'll put it on CPAN (but I'm not sure how to write portable tests for 
it yet.)


       This module enables you to integrate mail as "just another output
       method" for an automated process.  This is useful if you can't
       get sendmail to do what you want with a cron job (or you have a
       job where the output should go to somewhere outside of
       localhost.)  Maybe also fun for tracking webserver and other
       daemon processes.

         use IO::Mail;
         my $config_file = $ENV{HOME} . "./.automail.conf";
         # ties to STDOUT (see new() to tie to other handles)
         my $out = IO::Mail->output(config => $config_file);
         print "this is the body of the message\n";

       If you want errors to be mailed to you:

         use IO::Mail;
         my $config_file = $ENV{HOME} . "./.automail.conf";
         # ties to STDERR
         my $err = IO::Mail->errors(config => $config_file);
         $problem and warn $problem;
         # if the mail works, you'll get this:
         $error and die $error;
         $abort and $err->abort(); # goes back to STDERR
         # If we got this far, you might still want
         # the collected messages in your inbox.

"Left to themselves, things tend to go from bad to worse." 
                                       -- Murphy's Corollary
3/22/2005 12:02:37 AM
perl.module-authors 1604 articles. 0 followers. Follow

1 Replies

Similar Articles

[PageSpeed] 31

# The following was supposedly scribed by
# Eric Wilhelm
# on Monday 21 March 2005 06:02 pm:

>The code is in my subversion repository, synopsis below for
> convenience.

Wow.  Ditching the tied filehandle and switching to open($handle, '>',=20
\$scalar) does wonders for my sanity.

Haven't tried to go back to the destructor-based send process.  I ran=20
into trouble with IPC::Run because I hadn't implemented the full=20
interface for the tied handles.  Anyway, the object wasn't really a=20
tied handle.  Rather, the point was to make writing mail as simple as=20
printing to the console.  So, for instance you might have this=20

my $mail;
if($mailto) {
  $mail =3D IO::Mail->output();
    To =3D> $mailto,
    Subject =3D> "incoming files",
print "$num files in $time seconds\n";
$mail and ($mail->send());

"Politics is not a bad profession. If you succeed there are many=20
rewards, if you disgrace yourself you can always write a book."=20
                                            -- Ronald Reagan
3/23/2005 3:14:08 AM