Terry Jones wants the end of me, so let's have the end of one another. His
and my approaches are divergent: I prefer an answer within what I'm already
doing so as not to need to keep its motor running in neutral while I do
something else, while he insists on one within what he already knows. That's
why we reached different solutions.
J> ... but yours needs De Morgan's laws to be understood by anyone other than
J> a first-order logic major.
Then how do I, who never took a logic class and have no degree, know them
well enough not just to read but to write code that uses them?
When I was in elementary school, set theory -- including ~A v ~B = ~(A /\ B)
and ~A /\ ~B = ~(A v B), which are equivalent to DeMorgan's laws -- was
taught to nine-year-olds in regular classes (not just to advanced groups).
As Dan Smith has posted, procmailrc syntax was designed and has grown speci-
fically for throwing mail, and it was never intended to be a dialect of awk
or perl. [When the !(!A & !B) trick for ORing was pointed out to Stephen van
den Berg, the pivotal part where "{ }" functioned as a place-holding no-op
was an accidental feature that came as a surprise to him.]
J> And as you know if the expression were just a little more complex, your
J> recipe would become more inscrutable very rapidly, but the perl statement
J> would not.
Of course: the perl statement is already inscrutable to someone who hasn't
studied perl or the languages on which its syntax is based, so further com-
plexity can't make it worse. The question is "Inscrutable to whom?"
J> If you agree with this (and how could you not?), then you may also agree
J> that the perl solution will be more accessible (to these procmail novices).
^^^^^^^^^^ ^^^^^
One key word there is "these". Mr. Jones limits the sample in advance to
people who
(1) are familiar with perl or awk;
(2) are unfamiliar with procmail;
(3) intend to remain unfamiliar with procmail; and
(4) are on single-user systems where they can use all the simultaneous
processes and all the RAM they want without answering to anyone else.
He's right: they'll all prefer the perl code that they already know, will ob-
ject to a procmail solution that they don't already know, and will not care
in the least about saving processes; and truly, I must agree with him about
how they'll feel, as much as I disagree with them about feeling that way.
The other key word is "accessible". Yes, such people already know what they
already know and do not yet know what they do not know. I couldn't disagree
with that either.
T> My sole argument for advocating the latter form is to save forking perl
T> when you're already running procmail.
J> OK, I'm with you all the way on this. If you can avoid forking processes I
J> think that's great, but some of the things you need to do to make sure of
J> this should be done in the privacy of your own .procmailrc file, and not
J> forced upon innocent newcomers.
"Forced"? Whom am I forcing? Mr. Jones, if you fork perl during procmail
to test whether an incoming message contains the letter `e' I won't get in
your way, not even to recommend grep over perl.
Moreover, any newcomer who already has a situation that requires the mixture
of ANDs and ORs we've been discussing here is far past innocence.
J> My only argument, and one that I think you have helped me make, is that
J> the bizarro procmail syntax (especially if extended in some of the ways
J> that have been suggested) will be more difficult to newcomers than
J> something like a bit of perl (in either case backed up by examples).
If one posits a world where everyone is born speaking awk, then indeed, perl
is a snap while procmail still has a learning curve in that world.
Mr. Jones, my suggestion differed from your preference, but that hardly jus-
tifies extreme terms such as "bizarro" and "forced". If my suggestion does-
n't work, correct it; if it is performs more poorly than yours (and not just
if it less to your liking), tell us why. (For example, I thought that your
perl test was intrinsically poorer because of the extra process; I said so
and offered an alternative.) If it's harder for you to understand, ask for
an explanation. But your long, vocal beefs with my code boil down to its
being something that you did not already know.