Donald Hammond asked,
| [D]o INCLUDERC statements function as a kind of "call" which returns
| control to the "original" rc file if processing falls off the end of the
| included rc file?
Yes.
| Or if processing falls off the end, does mail then get delivered
| to $DEFAULT and processing stop?
No ... unless there is nothing left in the main rcfile after the INCLUDERC
call, and when processing returns to the main rcfile, procmail falls of *its*
end.
| What I would like to do is have a series of statements like:
|
| INCLUDERC=$PMDIR/.procmail_killrc
| INCLUDERC=$PMDIR/.procmail_friendsrc
| INCLUDERC=$PMDIR/.procmail_spamrc
| INCLUDERC=$PMDIR/.procmail_tmprc
|
| in a file $PMDIR/.procmail_mainrc (that is included from ~/.procmailrc)
| to process "related" recipes in turn, then (if not successful) pass
| control to the next rc file until a successful delivering recipe is
| executed or processing falls of the end of the _last_ INCLUDERC.
That's the right way to do it.
| ... or will these need to be "chained" together with an INCLUDERC to the
| next file at the end of each one?
That's unnecessary and probably harder to maintain, as you would have to
examine each rcfile in turn to see what the next one is instead of having
a list in one place.
Putting all the calls into the main rcfile, one after another, will work as
expected. If you want mail that gets to the end of an INCLUDERC delivered
to $DEFAULT rather than returned for further processing to the rcfile from
which the INCLUDERC was called, you need to close it with an explicit recipe
that delivers to $DEFAULT.
| It probably doesn't matter for this question, but just in case, I am
| working with two different versions at two different accounts:
|
| procmail v3.11pre5 1997/04/03
| procmail v3.11pre4 1995/10/29
No difference for this particular question; however, 3.11pre5 and pre6 had
some bugs, so it really should be upgraded to 3.11pre7. It would be a good
idea to upgrade both, in fact.