dattier(_at_)wwa(_dot_)com (David W. Tamkin) writes:
It does log pipes and forwards if that's the last thing procmail does. If
procmail pipes or forwards a copy based on a recipe with a `c' flag, then
LOGABSTRACT=all fails to operated properly and doesn't log the action.
Yup, that was my complaint !
The rather inefficient workaround is to spawn a clone: change
:0c other flags
* conditions
| command # or ! addresses
to this otherwise ridiculous syntax:
:0c condition-related flags
* conditions
{
# only way to make 3.11pre7 log piping or forwarding of a copy
:0 action-related flags
| command # or ! addresses
}
Ridiculous, maybe, but I admit I didn't think of that one !
Thanks!
That way the delivery of the copy is the last thing that the clone procmail
will do, so the clone will log it.
On another hand, the semanticas will not be exactly the same. Example
(you'll recognize maybe the same code-shape as in my question about processing
after delivery):
:0 cw:some.lock
| rcvstore +somefolder
:0 a
| send-note-about-delivery
because the ":0 a" will most likely not be able to depend on the success of
rcvstore if I move rcvstore into a forked subblock.
Note that this is not necessary when a copy is delivered by procmail's saving
it to a folder.
Since I need the "unseen" sequence to be updated, I can't use procmail's own
delivery and have to go through rcvstore !
Stefan