On Thu, May 13, 2004 at 05:30:59PM -0700, Professional Software
Engineering wrote:
At 01:41 2004-05-14 +0200, Dallman Ross wrote:
MATCH # unset this first to avoid contamination from earlier recipes
Well, if each of the conditions specified a match, and one of them must
match in order for the braced action section to be processed, I suspect
this is rather unnecessary. Under what circumstance could you reach the
action if nothing matched (which would have redefined MATCH)?
Yes, you're right that in the particular recipe it was not necessary. I
was operating under the assumption that the simplified recipe snippet
shown might not be what's actually put into production. Or the recipe
or its underlying algorithm might morph over time or at a later date.
When you get an errant match from an earlier use of the match token and
have to spend an hour tracking down why, you start to make it a habit to
unset your matches from the git-go. :-) (Been there, done that. Have
had recipes that match on errant stuff, where I didn't know it, for
many months in operation, and only found it after some bizarreness and
subsequent head-scratching. When recipes, singly or in a group, are
more complex, it gets even harder to troubleshoot.)
I have also recently gone to quoting my assignment statements with
(an attempt at) regular consistency. I almost never used to quote my
assignment statements in procmail. You don't even technically need to
quote a whitespace char, as it turns out, as this will work:
TAB = " "
foo = $TAB # no quoting needed!
E.g., plug this into your sandbox and see, following the above:
:0
* $ ^Subject:.*$foo
{ kilroy_was_here }
But try and debug a surfeit of unquoted stuff, and you will give
yourself a headache fast. Just asking yourself each time, "Does
*this* one need quotes? *This* one?" gets old, and tires the brain
trivially. So sometimes a programmers' conservative habit of quoting
just about anything non-numeric is the better rule. Then you don't
have to remember to ask yourself, each time you code a new statement,
"Is this one ever going to be mis-parsed? Is it ever going to contain
whitespace, even if I didn't consider it in my first cognitive
inspiration about what I'm doing?"
So I've accepted what my coder friend Mike has taught me, and tried to
adopt safe programming habits for consistency's sake even when they may
not be necessary in a particular place. Always pre-initializing
vars is one such habit.
I admit that I don't always pre-initialize MATCH when it is trivially
obvious in a brutally simple recipe that it is unnecessary to do so.
Brutally obvious code snippets are, by definition, though, self-
documenting. When it slowly evolves into a labyrinthian puzzle,
as some of my anti-spam recipes have done over time (to my unending
personal chagrin - they need to be rewritten!), then it starts
to get too hard to think through each time . . .
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail