At 09:36 2003-01-05 -0800, Scott Stark did say:
Hi, I'm trying to get procmail to do three things:
1) save messages with "FRAMEWORKS" in the To: field
2) execute a Perl script (process_procmail.pl) on the saved message file
3) send a copy of the message on to me in my regular mailbox
I've gotten the first two to work fine (with one weird problem, more on
that later). How can I get #3 to work as well? Here's my recipe:
:0c
* ^To:.*FRAMEWORKS
/u/home/mydir
You're not locking the write, so if you get concurrent message deliveries,
you're going to hose the file. Also, does your perl script (elsewhere)
_delete_ the file when done with it, or are you running it on the growing
file? I suspect you want to delete it if you're passing it through a program.
FTR, $HOME should have your home path in it, so you can write recipes
without having to hardcode your own home dirname in them.
:0c
* ^To:.*FRAMEWORKS
${DEFAULT}
Is this intended to bypass all subsequent filters, or are you just writing
it to default because you want to deal with this before the following perl
invocation? Again, you're not LOCKING the write...
:0 hfwi
f = filter - this is supposed to _change_ the passed message. I really
suspect you shouldn't be using this - but since you haven't provided a
description of what the perl script is supposed to be doing, and why
procmail should or should not care about the results, it's impossible for
me to know.
h = you're piping only the headers
w = wait for exitcode and don't consider it filtered (i.e. RECOVER the
message) if the script returns a non-zero exit. Is there REALLY a
condition you're going to do this, because all this means to you is that
the message will show up AGAIN in your mailbox because it'll pass through
to the rest of your procmailrc
i = ignore errors caused by the script not reading the entire file (my
guess is that you're not really using the passed message at all, so this
filter is appropriate).
* ^To:.*FRAMEWORKS
| /u/home/mydir/process_procmail.pl $LASTFOLDER
What do you figure LASTFOLDER will be set to at this juncture? Your filter
ordering will dictate that this is running against your $DEFAULT mailbox,
not the file you stored the message in explicitly above. I strongly
suspect that this isn't what you want to be doing.
My other (weird) problem is that sometimes my personal emails (those that
do not meet the FRAMEWORKS test) come through with FRAMEWORKS emails
appended to them. Why would that happen?
Because you're not LOCKING your writes. See 'man procmailrc':
By using any number of recipes you can presort your mail extremely
straightforward into several mailfolders. Bear in mind though
that the mail can arrive concurrently in these mailfolders (if
several procmail programs happen to run at the same time, not
unlikely if a lot of mail arrives). To make sure this does not
result in a mess, proper use of lockfiles is highly recommended.
Now, let's throw all your recipe away and start over. Note that the
condition is checked for only once (why keep checking it if you know
they're all based on the same condition). I assume you deliver to $DEFAULT
because you want to bypass all subsequent filtering which the message might
be subjected to -- otherwise, follow the directions in the note in the filter.
# surely there's something more specific you can trigger on?
:0
* ^To:.*FRAMEWORKS
{
# save a copy to our regular mailbox
# delete this recipe and put a c flag on the one above if you
# want the copy to be subjected to your other filters.
:0c:
$DEFAULT
# save a copy to the file for the script. Note that we
# specify a lockfile for this PAIR of filters - procmail won't write
# to the message file while another procmail process is running the
# script...
LOCKFILE=$HOME/mydir/process_procmail.pl$LOCKEXT
# presumably this file is ONLY used from within
# this rc, so with the above lock, we shouldn't need
# to lock this specifically.
:0c
testfile.msg
# Then, run a perl script against it.
# presumably, this script deletes the file when done...
# w flag means that if the script returns a failure, you'll
# get THIS copy of the message AGAIN in your mailbox...
:0 hwi
| $HOME/mydir/process_procmail.pl $LASTFOLDER
# clear the lockfile
LOCKFILE=
}
It never happened until I started using Procmail.
It never happened until you started misusing procmail. You can't hit your
thumb with a hammer unless you're using a hammer - but that doesn't mean
it's the hammers fault when you do.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail