Philip Guenther wrote,
| I've thought about how to make a tail-recursive INCLUDERC, probably
| with a name like "SWITCHRC", as that would eliminate the recursion
| overflow, but I've never gotten around to it. It would abort
| processing of the current rcfile and start processing the named file
| instead, leaving intact the stack of rcfiles from previous INCLUDERCs.
Would it be allowed in the base rcfile? I don't see why not: "move there
and do not return." It would be equivalent to this, except for the stack
depth:
:0 flags
* conditions
{ INCLUDERC=the_file_for_switchrc }
:0E
{
entire remainder of first rcfile
}
Maybe you could use the name of a familiar shell built-in and call it EXECRC
(because it replaces the rcfile that called it just as an execked process
replaces the one that called it).
And of my ORing logic proposal,
| The trick with extending procmail's logical constructs is that you want
| to make them a) programable, c) powerful, and c) explainable. I would
| guess that your proposal meets (a) and (b), but I have doubts about (c).
Which (c) raises doubts with you? You have two of them.
| Can it be explained in a one paragraph blurb in the list of recipe flags?
Oh, the second (c). OK:
o: OR conditions instead of ANDing them; recipe is a match if
any unweighted condition matches or if net score is positive
Short enough, Philip? What I posted before was the full detail, and it
was not intended as the summary version. Actually, the only parts missing
from the synopsis above are what happens if the score reaches supremum or
infemum with some conditions still untried.
I was not attempting a syntax for mixing and grouping ANDing and ORing within
a single recipe.