On Sun Dec 15 1996, Alan Stebbens wrote:
Subject: Re: using MATCH for getting folder destination names
On Mon, 16 Dec 1996, Tony Nugent wrote:
I'm subscribed to several linux email
lists and use procmail to put these messages into mh folders which
have names based on the name of the respective list. (I've found
mh to be a very good mailreading package).
For example, `linux-net' goes into ~/Mail/net/., `linux-admin' goes into
~/Mail/admin/. and so on.
... all these recipes
are very similar and that using the `MATCH' variable might make it
possible for me to greatly simplify things so that *one* recipe is
used for delivering messages from each of these lists!
Please read the procmail tutorial which explains a "prefiling"
method I use for just the problem you are describing. This
tutorial and the recipes it describes are available from my procmail
recipe library, which you can obtain by sending me a mail with
the subject of "send procmail library", or by browsing my
web page under the "mail" or "depot" links.
Here is a small snippet from my own .procmailrc to do this kind of
prefiling:
...
ADDR=procmail DEST=info/procmail/. INCLUDERC=mh-check.rc
ADDR=SmartList DEST=info/smartlist/. INCLUDERC=mh-check.rc
ADDR=mh-e(_at_)x(_dot_)org DEST=info/mh/.
INCLUDERC=mh-check.rc
...
# Finally, after all that, save the message
INCLUDERC=mh-save.rc
Thanks for pointing me to this, Alan. I have read this before, but
didn't recognise this as a possible solution.
However, after considering this I'm confused about several things.
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.
I'm not sure where I got this impression but I'm sure I saw it in some
documentation somewhere - a `mini-tutorial' I think... perhaps it was
describing an earlier version of procmail. The man pages mention
INCLUDERC only briefly and certainly don't mention rc flow control.
However, your method implies that this is not the case, where the same
rc file is called multiple times (returning control to the calling rc)
and then a different one called at the end of all that. If this is
what procmail does, then I can see that this behaviour is very useful.
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?
Is the syntax of declaring multiple variables (separated by
whitespace) on the same line "legal"?
The tutorial specifies INCLUDERC=pf-check.rc (mh-check.rc is not
included in your library) which basically consists of five lines
(which would otherwise need to be repeated for each ADDR/DEST pair):
:0
* ADDR ?? .
* DEST ?? .
* $ ^TO$ADDR
{ PF_DEST="$PF_DEST $DEST" }
This is looking for a match on one character??? I don't understand
the symantics you have here of matching a variable against `.' (one
character).
The confusion about how INCLUDERC works aside, I'm not sure if what
you describe in your tutorial is exactly what I was looking for,
although I must admit that there is a eligance with all this that I'll
certainly incorporate into what I eventually develop for my own
purposes. Your method certainly by-passes the question of using MATCH
to get the name of the destination folder - although I still think
that this would also be a valid approach which would negate the need
for calling a *-check.rc file.
For example, I want to identify and explode digests (I use mh btw),
and handle any Cc's to me that are filed with these recipes by placing
copies into another separate folder (neither tasks are difficult to do
in the *-save.rc files).
Thanks for any clarification of this.
BTW Alan, do you have your *.format and *comps files available
anywhere? I'd like to see them...
Cheers
Tony