Terry Jones wrote,
| IMO neither of those ways of working ORs into the procmail recipe
| syntax are worth much :-)
I'd put it differently, but Martin's and Stan's suggestions do seem to stir
up more problems than they solve. What about an old rcfile with :n syntax
that gives the actual number of conditions, some of which start with a symbol
that Stan now suggests making special? And Martin, I know we've had our
disagreements, so I hope you understand that I mean nothing personal by this,
but making indentations significant would wreak hell with existing rcfiles.
| Yes, I know you can do everything with a handful of NAND gates,
... or with NOR gates, for that matter, but then you're dependent on correct
parenthetical grouping.
| but that doesn't mean you have to!
Right; you don't.
| You could do this for example [with Terry's spamometer script in perl]:
|
| :0i
| * ? spamometer -i your-perl-file
| mail/XXX
|
| :0i
| * ? spamometer -i your-other-perl-file
| mail/ZZZ
| Instead of 20 lines of indecipherable procmail recipe, you can have
| elegant recipes exactly like the above, and 20 lines of indecipherable
| perl!
Getting gobs of code out of the .procmailrc into a different file isn't the
issue; if it were, the INCLUDERC facility already handles that.
You want to see a simple way to AND and OR to your heart's discontent in
procmail?
(A and B) or (C and D):
:0
* 1^0 A
* 1^0 B
* 10^0 C
* 10^0 D
{ }
SCORE=$=
:0 # if SCORE is 2, 20, or 22, we're in business
* SCORE ?? 2
action
Granted, it shouldn't bother evaluating C or D if A and B are both true, but
gaining that efficiency is complicated, unlike the case of simple ORing,
where we can do that by substituting maximum weight for 1^0 (and one list
member is on record as considering even *that* to be complicated).
For (A or B) and (C or D):
:0
* 1^0 A
* 1^0 B
* 10^0 C
* 10^0 D
{ }
SCORE=$=
:0 # if SCORE is 11, 12, 21, or 22, it's a go
* SCORE ?? [12][21]
action
Again, to be more efficient it should skip evaluating B if A is true and not
bother with D if C is true (nor with C or D if both A and B are false), but
those are impossible without complicating the syntax.
The ways I'd code those two cases within procmail (no forks) are appended
after the row of underscores so that anyone who doesn't care can skip ahead
from that point.
| Use procmail for simple things and if you have some complicated work to
| do, use a real programming language. It's easier for everyone to learn
| (don't tell me you have to be a programmer to understand a bit of
| perl, or that it's harder to understand some nice perl than some of
| the obscure procmail recipes that float around here), and no-one needs
| to strap on another layer of syntax to procmail.
Slow down, Jones. Perl is easier to learn than procmail? Only if you al-
ready are familiar with C! I learned procmail code by studying examples and
trying things out; but perl remains gibberish to me, and every perl proponent
who has touted it as a snap to master has ended up conceding, yeah, well,
perl's syntax is derived from C's, and he or she just assumed that all humans
are born fluent in C, but since I'm a non-C-speaking freak, he or she can see
how perl would be opaque to me.
| Well that's just my opinion. I may change it tomorrow, so don't take
| it too seriously.
That's OK, Terry. Nobody ever does.
| Then we could get really bizarre.
Short trip.
___________________________________
(A and B) or (C and D):
:0
* A
* B
action
:0E
* C
* D
action
(A or B) and (C or D):
:0
* !A
* !B
{ }
:0E
* !C
* !D
{ }
:0E
action
More complex situations can be handled by setting or unsetting a variable
whenever part of the expression is satisfied (or unsatisfied), and then
finally testing the contents of the variables; when it gets to that point,
though, a perl lover will understandably want to fork perl instead.