This is a follow-up to
http://www.rosat.mpe-garching.mpg.de/mailing-lists/procmail/2001-12/msg00488
.html
There is an important step missing the proposed, partial solution:
2) pipe the output to the "tee" command:
*^From hylafax
| tee -a hylafax-li >> common.mbox
This isn't as efficient as Martin's solution, because it creates a shell
process to run
the "tee" command, but it is terse, and should work fine for infrequent
use.
The recipe above doesn't show any locking rule, and one is required. At
first glance, we might think that the default local locking (i.e., ":0:")
won't work here, because this recipe writes *two* mailboxes, and if other
rules attempt to also write the same common mbox (named "common.mbox"
above), then some sort of global lock is required. We might choose a lock
file name that is simply the common mailbox name with the default lock
extension, $LOCKEXT (".lock") appended to it, like this:
:0: common.mbox$LOCKEXT
*^From hylafax
| tee -a hylafax-li >> common.mbox
But, it turns out that this is in fact, procmail's default local locking
behavior, per "man procmailrc":
Local lockfile
If you put a second (trailing) ':' on the first recipe line,
then procmail will use a local lockfile (for this recipe
only). You can optionally specify the locallockfile to use;
if you don't however, procmail will use the destination
filename (or the filename following the first '>>') and will
append $LOCKEXT to it.
Thus, as long as our global, common mailbox is listed last, after the ">>",
we can use the default local locking syntax:
:0:
*^From hylafax
| tee -a hylafax-li >> common.mbox
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail