On Thu Dec 19 1996, "Alan K. Stebbens" wrote:
As usual Alan, your reply is absolutely invaluable... whoever is
maintaining the `best-of-procmail' archive (who is this, btw?)
hopefully has spotted and saved off your message for inclusion :-)
This method you describe involves several INCLUDERC files. I was
under the impression that only one include file is allowed, and once
flow goes an INCLUDERC file, then it does not return to the calling rc
file.
You can use INCLUDERC as many times as you like, and you can nest them
also (just don't make the nesting cyclic!).
Each address must be checked, and "mh-check.rc" is the subroutine which
does the checking.
Then I can assume that procmail treats INCLUDERC files like
subroutines, with control going back to the caller. This is good, as
I now understand that it is possible to totally modularise
~/.procmailrc.
Great to have this point clarified, as I had been totally mislead
about this by something I read somewhere.
Even if this was the case, wouldn't it be more efficient to only call
another rc file when an initial match is made and not for each check?
This of the following condition:
* SOMEVARIABLE ?? .
as a procmail colloquialism for the statement:
if SOMEVARIABLE is set
Ahh, I see. This is a procmail thing. Thanks for this hint (which
I'm sure I didn't see mentioned in any of the man pages).
The reason why you want to accumulate all of the destinations and
file them all at once, together, is so that procmail can perform
the hard-linking between them all.
They are _linked_? Ahh, now I understand what the man page is talking
about. But what if I want them to be separate messages (ie, not
hardlnked with the same inode)? (Indeed, is there any advantage -
apart from the saving in disk usage, for using hardlinks over straight
copies).
That's one of the beauty's of procmail -- you can make it work however
you like! And, it is easy to "adjust" an existing recipe.
For example, if you choose to use "pf-check.rc" and "pf-save.rc", you
can still have dynamic folder creation by modifying "pf-check.rc" so
that it does something like this:
pf-check.rc:
[munch]
Then, you can write recipes like this:
DEST=MATCH # all of the following recipes use $MATCH for
filing..
DEST_PREFIX=info/ # these get filed into subfolders of the +info folder
DEST_SUFFIX=/. # and they are MH-style folders
ADDR=procmail INCLUDERC=pf-check.rc # folder == info/procmail/.
ADDR=perl-users INCLUDERC=pf-check.rc # folder == info/perl-users/.
ADDR=info-gnu INCLUEDRC=pf-check.rc # folder == info/info-gnu/.
ADDR=mh-users INCLUDERC=pf-check.rc # folder == info/mh-users/.
In fact, this is such a useful idea, that I'll incorporate it
into my recipes. Thanks for the idea!
Hey, no problems Alan - I'm glad to help! :-)
BTW, here are the all of the mh-*.rc files, straight from my
Mail directory. Use at your own risk.
Way cool. Have I thanked you enough? :)
One question about using procmail with mh... when procmail deposits
messages into mh folders in numbered sequences, the `unseen' sequence
isn't updated.
I'm thinking of making the actual delivery using /usr/lib/mh/rcvstore
so that this will occur. However, the man page states:
BUGS
If you use the "Unseen-Sequence" profile entry, rcvstore could
try to update the context while another MH process is also trying
to do so. This can cause the context to become corrupted. To
avoid this, do not use rcvstore if you use the "Unseen-Sequence"
profile entry.
In other words, it has a lockfile problem (that is, it doesn't use
them). However, I do use /usr/lib/mh/rcvstore for delivering digests
and I've never had a problem with this. (I suspect the problem hasn't
shown up because only one digest at a time is being delivered and each
of those messages in sequence rather than in parallel).
Is there a solution to this so that mail is delivered and the `unseen'
sequence is updated?
If there isn't, then I'll have to rely on the presence or absence of a
`Status: ' line (which I can get mh's `anno' command to add once I've
read a message - but this approach has its own problems).
Anyway, with the info you've given me I've now got some work ahead of
me redesigning my ~/.procmailrc and testing it! :-) Thanks again.
Cheers
Tony