procmail
[Top] [All Lists]

Re: strlen() in procmail

2003-01-15 15:27:01
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

<Prev in Thread] Current Thread [Next in Thread>