[ Forwarded to the PROCMAIL list. I accidentally sent it to Phillip
rather than the whole list like I intended. ]
From guenther(_at_)gac(_dot_)edu Tue Nov 26 08:56:41 1996
Subject: Re: Simple combining recipe question
In-reply-to: Your message of "Tue, 26 Nov 1996 08:01:47 PST."
Date: Tue, 26 Nov 1996 10:56:34 -0600
From: Philip Guenther <guenther(_at_)gac(_dot_)edu>
bodysurf(_at_)netcom(_dot_)com (Tim) writes:
No need to do the HOST trick when you have something to do any actual
I don't even know what the "HOST trick" does. I just put the "HOST" in
there because I thought it was necessary. Why exactly is the "HOST"
necessary when there is no actual delivery action?
The HOST trick is the most efficient way to stop processing your
To quote the manpage:
HOST If this is not the hostname of the machine, pro-
cessing of the current rcfile will immediately
cease. If other rcfiles were specified on the
command line, processing will continue with the
next one. If all rcfiles are exhausted, the
program will terminate, but will not generate an
error (i.e. to the mailer it will seem that the
mail has been delivered).
When you just say "HOST", you unset it. Unsetting it means it doesn't
match the hostname of your machine, so procmail stop processing that
rcfile. Since it's almost certain that procmail is processing only one
rcfile, that'll stop processing the email.
In your case, since you have a recipe to act as a delivering action,
you can just you that to terminate processing.
I'm gonna have to look thru the PROCMAIL MAN pages to see how that would
differ than doing a:
DELIVERED = YES
BTW: do you want the lockfile to be in the same directory as the file
I don't know. Does it matter? I don't think it matters where the
lockfile is in my $HOME directory as long as it does its job, right? I
mean the file is just there temporarily while the recipe is being executed.
It doesn't matter _that_ much, but it's considered "good form" to put
lockfiles in the same directory as the file they're locking. Perhaps
the best solution for this case would be to let procmail choose the
lockfile for you. It can do this because of the ">>" in the action.
| gzip -fc >> $PMDIR/headers.gz
procmail will use the lockfile $PMDIR/headers.gz.lock The nice thing
about this is that a) nothing bad will happen if two copies of procmail
are running with different MAILDIRs, and b) there's no possibility of a
conflict with another recipe using the same lockfile for a different
For a worst case scenario, consider if you used INCLUDERC to include
a 'library' recipe that sometimes (but not always) changed MAILDIR.
This could result in multiple procmails writing to the same file with
different lockfiles. For paranoia's sake you should either specifiy
both the lock and the file as relative paths, both as full paths, or
let procmail choose the lockfile.
Or you can just take this as practice in defensive programming.
One more question if you don't mind :^). Should I put a "w" argument on
the above recipe to make sure that the GZIPping is done before the recipe
exits? I was looking at the LOGFILE and it seems like PROCMAIL continues
on with the additional recipes in my PROCMAILRC before the GZIPping is
done. I just don't know if it makes a difference. I would assume it
doesn't because you didn't put it in there :^>.
If the gzip failed for some reason (say, disk full), is there anything
you would do later in the script given that knowledge?
Actually, it isn't completely clear to me what the 'w' and 'W' flags
actually do. If you look at the source code you'll find that in some
cases, procmail acts as if you had put a 'W' flag on the recipe even
if you had put nothing. I put a 'w' on if I'm feeling like I want to
be paranoid about the action taking place, and I leave it off if I
don't really care.
Anyway, you probably should have replied back to the list, as then
the others could chime in on this point. Feel free to send this on
to the list if you feel like it.
Sorry, I hit the wrong reply. Now it's (hopefully :^}) to the list.
Thanks again for the help.
"Finger" for PGP v2.6.3ia Public Key