>>>>> "M" == Marc  <sono...@fannullone.us> writes:

  M>    Thanks to both Uri and John for their input.  I've added your 
suggestions and the script is much cleaner and more concise now.
  M>    I decided to keep the header info in the sub because I'm now setting 
the subject to the path of the error log, so at a glance I know where there's a 
problem.

  M> On Jul 18, 2011, at 8:50 PM, Uri Guttman wrote:

  >> it would be much cleaner IMO to collect the paths of the files you want
  >> and then process those paths in a sub. the rule is generally to collect
  >> the data you need and process later and elsewhere.

  M>    I'm sorry, but I'm not following you here.  Could you explain a
  M>    little more?

basically the rule is make subs/modules/whatever do something focused
and small and do it well. putting the mailer code inside the want sub is
doing two different things in one area. it can get confusing. maybe it
isn't confusing for this simpler case but things never stay simple. so
my idea is to break it up into two subs. the want sub just finds the
error log files and maybe keeps the path to the file. it can build up a
list of hashes for that (or just a list of paths). now this is simple,
focused, and easy to write and test. just a few lines of code inside the
want sub.

then you write a mailer sub that is passed that list of hashes. it knows
how to loop over that list and mail out the file in each iteration. it
just does the mailing. it can be again tested independently from the
find/want code, it can be rewritten to use slurp and other mail modules,
etc. it does ONE thing (mail out the error log) and does it well. it
doesn't care where or how the error log file was found.

this is a very clean separation of ideas. one part finds files to be
processed (mailed) and the other does the processing (mailing).

  >> but beyond this calling sendmail directly isn't cool anymore. there are
  >> many useful mail modules that make this easier and work with other
  >> mailers or directly with smtp. 

  M>    I searched for mail modules and there seems to be a million of
  M>    them.  Could you recommend a couple that you like?

i happen to use Mail::Mailer. it supports all major mailers with a clean
api. others will point you to different modules. but calling sendmail
directly is nasty and not portable.

here is some code i use for that. 

        my $mailer = Mail::Mailer->new( 'qmail' ) ;

        $mailer->open( {
                To      => $email_addr,
                From    => 'u...@zzzzzzzzzzzz.com',
                Sender  => 'u...@zzzzzzzzzzzzz.com',
                Subject => 'foo bar',

        } ) ;

        my $foo_text = join '', map "$_\n", @new_foos ;

        print $mailer $foo_text ;
        $mailer->close() ;


  M> find(\&wanted, $path_to_search);

  M> sub wanted {
  M>    return if $_ ne $file_name;

  M>    my $subject = substr $File::Find::name, length($path_to_search);  # 
removes "/home/USER/public_html" from the subject

bah. that is a very silly way to do that. also don't comment on the end
of a line as it word wraps and is harder to read.

        (my $subject = $File::Find::name) =~ s/^$path_to_search// ;

but you should do what i said and just collect an array of
$File::Find::name values. then you can pass that to the mailing sub. or
remove the prefix path for all of them:

        s/^$path_to_search// for @error_log_paths ;

then either loop over that and mail each file individually or have the
mailer sub do the looping. 

uri

-- 
Uri Guttman  --  uri AT perlhunter DOT com  ---  http://www.perlhunter.com --
------------  Perl Developer Recruiting and Placement Services  -------------
-----  Perl Code Review, Architecture, Development, Training, Support -------

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to