On Wed, 20 Dec 1995 21:08:00 -0600, pckizer(_at_)tamu(_dot_)edu (Philip Kizer)
wrote:
etlmcrt(_at_)etlxdmx(_dot_)ericsson(_dot_)se ("Marc Rackett (ETLMCRT
XB/VAC)") wrote:
As the condition lines are ANDED, is there an elegant
solution to OR them?
To OR, you need to use the regular expression syntax for OR-ing (see the
procmailrc(5) man page for details):
Yes, well, from a mostly aesthetic point of view, I think it would be
helpful and certainly more intuitive if the following could be
rewritten as one rule with many OR cases:
################## Spam && unsubscribes
:1
^Subject: .* FREE .*
spam~
:1
^To: liu-lysator-runeberg(_at_)uunet(_dot_)uu(_dot_)net
spam~
:1
^From: Ecstasy(_at_)euphoria(_dot_)com
spam~
# The installed procmail is a very old one, can't use :0
I can hardly imagine a good (and readable!) regexp to handle these in
one rule.
For one thing, adding a new case would entail adding a whole new
rule, which means four new lines to an already unfocused piece of
code.
Let's for example assume I could use a syntax like
################## Spam && unsubscribes
:0
?^Subject: .* FREE .*
?^To: liu-lysator-runeberg(_at_)uunet(_dot_)uu(_dot_)net
?^From: Ecstasy(_at_)euphoria(_dot_)com
spam~
Now adding one single case means adding one line to this rule, instead
of adding a whole new rule. Saves typing, which means it's less prone
to typos, it's more compact to read, and it won't cost much to
implement.
(And then they'll ask for a mechanism to OR ANDed ORs ;^)
/* era */
Yes, the example rules I use are rotten. They were born as solutions
to individual incidents and I never got around to fixing them. I
particularly like the first one :-)
Still, I'd appreciate any insights on what stupid risks I'm taking
with these rules. That's why I joined this list anyway ...
--
See <http://www.ling.helsinki.fi/~reriksso/> for mantra, disclaimer, etc.