Bart Schaefer <schaefer(_at_)zanshin(_dot_)com> wrote:
On Tue, 14 Jan 2003, David W. Tamkin wrote:
weighted conditions, $= is reset to 0.)  If your criteria include
preserving $= without saving it in an ordinary variable, your quest
is hopeless.
I don't really have an argument with what David said, except that
whenever I read "best way," "only way," "impossible," or "hopless,"
my mischievous mind starts churnging.  Here, I can think of lots
of alternatives to "hopeless" -- none of them particularly realistic
or good, though.  But, just to play devil's advocate, how about:
        | cat $= > somefile
Okay -- I didn't answer this message to discuss David's remarks
anyway.  That was just a what-the-hell.  I wanted to share my
approach, which ends up being essentially identical with what
David ultimately ended up floating/suggesting.  Trouble is, though,
that Wednesdays I am gone for 13 hours straight, so David answered
before I could.  Not that I feel we're in some kind of competition
or anything.  But I just wanted to be able to say, yes, that
stuff really does work, and in a well-tested environment.
In a follow-up message, David wrote:
Will you settle for this?
 *  1^0 ^In-Reply-To:[^<]+<\/[^>]+
 * -1^0 ^In-Reply-To:[^<]+<[^>]+
It means an extra scan of the head, but it leaves the currently accumulating
score untouched and changes $MATCH only if it should be changed.
Another possibility is
 *  -.000001^0 ^In-Reply-To:[^<]+<\/[^>]+
which is very highly unlikely to change the reported integer value
of $=, very highly unlikely to make an otherwise positive score
non-positive, and guaranteeed not to make an otherwise non-positive
score positive.
And that's exactly how I do it.  I have in my ENV area of the rc:
  TEENSY       = 0.0000000001        # _de minimis_ positive decimal fraction
  DRYRUN       = -$TEENSY            # tiny neg decimal aids compound matching
I use the second a lot more than the first.
I like the name DRYRUN, because it tells me that I'm testing for matches
but don't intend to disturb anything or blow out of the recipe on failure.
I call a padded supremum GO, and its inverse STOP.  That tells me at a
glance what I expect to happen with the various scores.
Here's a snippet -- slightly changed from, but drawing heavily on,
something I do use -- using DRYRUN and GO to look for the last part of
an address -- the ISP and TLD part -- and then go right to the action
line if that is matched in the lowest Received: header (which I have
saved earlier to the var shown).
  * $   $DRYRUN^0  ^Return-Path:(_dot_)*(_at_)\/$SOMEISP
  *                 MATCH    ??  ()\/[^.]+\.[^.]+^^
  * $       $GO^0   BTM_RCVD ??  ()\<$\MATCH\>
There are some scoring recipes where I rely on a "TRUST" calculus
that is a whole number.  If I use DRYRUN there, it will pull me
down a notch.  So on those, I first pad my TRUST value with
"$PADDING", has been set to 0.1.
| Perhaps something along the lines of
|
| * (|^In-Reply-To:[^<]+<\/[^>]+)
That was an interesting idea, btw, Bart.  The other day I was toying
with something like the following as a way to have a comment in a
condition line:
        COMMENT = (
        ENDCOMMENT = )?
        * 1^0  $COMMENT: We're adding 1 because blah, blah $ENDCOMMENT
Well, maybe cheezy, but it was late, and it was just and idea . . .
-- 
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail