"David W. Tamkin" <dattier(_at_)Mcs(_dot_)Net> writes:
2. A $LEVEL or $DEPTH read-only variable that would say how deep in
INCLUDERCs procmail is, so that we could take steps to prevent recursion
overflow and do other things for which it helps to know how deep we are.
It would be 0 in any rcfile being read because it was named on the command
line or used by default where none was named on the command line, 1 inside
an INCLUDERC called from a level-0 rcfile, 2 inside an INCLUDERC called from
level 1, etc.
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.
3. John wanted a way to deem a recipe matched as soon as the score became
positive to make for easier ORing. I'm not so sure that that's the way to
do it, as later recipes might make it zero or negative. Rather, this is what
I'd like to see (or dream of seeing, since I'm guessing it would mean major
code bloat): an `o' [for "or"] or `d' [for "disjunction"] flag -- please
don't make it capital O because so many newbies type ":O" instead of ":0" --
that would make the logic work like this:
<elided>
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). Can it be explained in a one paragraph blurb in the list of
recipe flags? Will it become a regular topic of explanation on this
mailing list? I would have to sit down and and play with it to see how
it would work out in typical usage before I formed a real opinion on
it.
My first thought would be a disjunction of conjunctions syntax, that
would look something like, say, this:
# a and b, or c, or d and e.
:0
* condition-a
* condition-b
** condition-c # or maybe "+ condition-c"
** condition-d # and "+ condition-d"
* condition-e
action
(Each conjuction would be treated independently as far as scoring went.)
However, I don't have any solid reason to believe that this would be
any easier to explain to or to be used by the non-programmer than your
proposal.
Philip Guenther