On Tue, 07 Jan 2003 07:22:18 -0500 (EST), dman(_at_)nomotek(_dot_)com wrote:
=> Thus, if the "cost" of a loose match is to lose mail or to
=> fail to stop a real looping message, we obviously don't want
=> that, and should choose to tighten the regex.
I see so many folks new to procmail filtering who send
their very first try in filtering unwanted email to /dev/null --
I worry that many cut-and-pasters (where I started) seem to not
understand that, in manipulating each character in a recipe, they
are playing with sharp knives.
=> "(.*\<)?" looks like about the ugliest smiley he's ever seen].
Indeed. May resemble someone new to the list, struggling
with the strange bits of procmail.
=> if I stick to recognizable conventions to handle similar
=> problems in a consistent way, then I have the advantage of
=> having employed a (partially) self-documenting phrasal style.
=> I like that concept.
One of my big-leap-forward moments with procmail came
when I reconcognized the obvious: $VARIABLES are great!
They 1) are easy to use, 2) can be [paritally]
self-documenting, 3) standardize usage, 4) mimize typo damage (as
"punction really counts"), 5) allow others (especially entry
level coders) to read the logic instead of stumbling over the
nit-picking rules of procmail syntax, etc etc.
IMO, macro coding (with variables) in procmail makes one
realize much more of its natural overall power. After all, it
really is code, not arcane magic, no matter what the underlying
syntax looks like.
Thanks again (and to all the active posters here),
- Don
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail