procmail(_at_)deliberate(_dot_)net wrote:
On Tue, 07 Jan 2003 05:05:07 -0500 (EST), dman(_at_)nomotek(_dot_)com wrote:
=> You do *not* control the header once you send it back into "space,"
Excellent point IMO and probably overlooked by many
(including myself). Thanks.
Welcome. (Don't recall ever before having written so many exclamation
marks in a note to this list.) :-)
=> :0 # 021129 () stop mail loops
=> * ! TEST ?? ^^(y|on)
=> * $ ^X-Loop:(.*\<)?${domKEY}bot$
=> {
=> logtext = X-Loop!
=> LOG = "$doubleAngle_L $logtext $doubleAngle_R"
=>
=> :0:
=> X-Loop
=> }
Thanks also for the recipe details. It's *always*
interesting to see how others handle all the details and side
issues of real-life recipes; and, it is quite instructive to see
I feel the same.
your testing for the EOL after the expected variable data.
Of course this recipe also matches the case where an
X-Loop header (with zero or more of anything) is followed
directly by a header consisting of exactly ${domKEY)bot.
Yes, good point to mention. In this case, it would lead to
a message's being saved to my X-Loop folder, where I'd find
and read it, so I made a conscious choice not to concern myself
about it. I do think it's valuable to evaluate importances.
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. Otoh, if the
cost is that a message might inappropriately be filed in a
different folder that one expects to read quicly anyway, then,
well, a standardized, albeit looser, syntax can be chosen without
the need to raise one's eyebrow.
I use "^Header:(.*\<)?" often (thanks to David Tamkin), even
though in my rc I have, early-on, defined "$WS" to a space and
a tab, so could more precisely write:
* $ ^Header:[$WS]*
[-- oh, and I use the former often despite one friend's comment that
"(.*\<)?" looks like about the ugliest smiley he's ever seen].
But there are some pedagogical/semaphoric/exegetic advantages to
using a known construct that does not, at the same time, require
explaining a private variable to others. As soon as I write
"[$WS]", the party casually parsing the code is likely to ask
himself, "Why is he calling up a private variable?" and, with that
shift of attention, to lose his concentration on what should have
been the underlying point of the phrase being examined. Otoh,
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. So I weigh it against the disadvantage of
the inherent looseness in "(.*\<)?" (there could be text in there,
after all, or a line-end), each time I choose to use it.
If the choice I as the coder make is always conscious, and
veering toward stylistic consistency, and if I've thought through
the down-side consequences ahead of time, well, I'm in like
Flynt. Here, for me, as I explained a couple of paragraphs up,
the disadvantages are minimal. (And what you warn of seems damn
unlikely here, in any case.) I do think it was helpful of you to
post the reminder, though. And I did note with interest your
mention of some months ago of \> and \<'s ability to move past
line-ends.
(Oh, as for why I don't just use "[ ]", the reason is that I
can't see the tab, and when I copy-and-paste code, I tend to
lose it, as it gets automatically converted to spaces in my copy
buffer. And that syntax, too, always requires explanation for
lookers-on, so I see no strong advantage over a consciously
selected substitute style.)
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail