Philip Guenther wrote,
| On Tue, 21 Jul 1998 11:43:44 -0700 (PDT),
| "John D. Hardin" <jhardin(_at_)wolfenet(_dot_)com> wrote:
| > 1) match original message, process/deliver original message
| > 2) match forked message, process/deliver original message
| > 3) match original message, process/deliver forked message
| > 4) match forked message, process/deliver forked message
|
| You can already do all of these right now: (1) is the normal situation,
| (3) and (4) are easy: just do the filtering before or after you do the
| matching. The only tricky one, (2), can be done using the trick
| described by David Tamkin:
Wait, Philip, you mean my suggestion WORKS? That has to be the best thing
about procmail I found by sheer dumb luck since the "{ }" no-op.
| :0 c:
| {
You'll need to name the lockfile there. But wouldn't a `W' or `w' flag do
the job instead of (and more efficiently than) a lockfile [unless some actual
file needs serialized writes]?
| # This is the "forked message". Filter and match, then
| # use EXITCODE to tell the parent what happened.
| :0 f
| | strip-attachments
|
| # failure by default...
| EXITCODE = 1
| :0
| * blah blah blah
| { EXITCODE = 0 } # ...unless success
|
| HOST # kill the child
| }
|
| # If the match in the child succeeded, deliver
| :0 a
| some-file
In the example I posted a couple days ago, the known action was on failure,
not on success, so it was wrapped up with a :0e recipe. For successes
procmail had to keep reading recipes.