From: Kevin Kelleher [SMTP:kevink(_at_)MIT(_dot_)EDU]
One of the first things in my .procmailrc is a call
to a perl script:
:0c
| $HOME/bin/clocker
This checks a flag file to see whether it has already
run today, and if so exits. If it hasn't, it
changes the flag file and then does a bunch of stuff,
Is it just me, or do others have a philosophical objection
to triggering the overhead of perl for every single message
that comes in when it is easy to do this by other, less
"inflationary" means?
I would (and do) use a more low-overhead way to
check the date. One way discussed here in the
past (by era, dattier, etc.) is to look at the time-stamp
on the incoming message and parse it for the new
date. (Once you know the date has changed,
*then* run your perl script.)
I use a different method, where a triggering
piece of mail from account elsewhere where
crontab is allowed writes the new date to
.incrc. At one time two years ago, the aforementioned
dattier (hi, David!) and I weighed my alternatives
and came up with a reason (now sort of forgotten :-)
why that would be better, in my case, than parsing
the timestamps. (I also do a series of complex things
once daily, including deleting procmail logs older
than 7 days, generating a file posted to USENET,
etc.)
In any case, reading an .incrc or parsing the
time-stamp of the mail has got to be better
than firing up perl each time.
--
Dallman Ross, IMO, ISSO
Supervising Programmer-Analyst
26th Area Support Group - S1 Automation Branch
DSN: 373-6779 . Civ.: 011-49-6221-176779
<rossd(_at_)heidelberg-emh11(_dot_)army(_dot_)mil>