procmail
[Top] [All Lists]

RE: Regexp fails in scoring recipe

2003-04-30 16:51:18
Kevin Wu [mailto:tessar(_at_)bigfoot(_dot_)com] wrote:

Dallman Ross wrote:

On Tue, Apr 29, 2003 at 04:45:01PM -0700, Kevin Wu wrote:

Does anyone know why procmail behaves inconsistently between
production mode and test mode (see the diagnostic output below)? 

Uh, it's not that I don't appreciate your detailed analysis, but it 
doesn't answer my question so perhaps I need to restate it. 

Heh.  Sometimes the best answers are to unasked questions.  :)


Why does my recipe as posted fail on the sample traffic report as 
posted when the message is delivered in production mode? 

I confess that I didn't look that hard at your log output; but
I did skim it briefly, and I didn't see why.  However, if your
mail is arriving on a separate server to that under which your shell
account is running, that could be one explanation.  That is how
things operate at the shell provider I use as my main account
and under which I run procmail.  Can you rule that out categorically
as a possibility?  Try putting this near the top of the .procmailrc,
from the recipe through the close-quote below the log entry:

:0 hi  # this is an assignment recipe, not a delivering one
PROCV_OUT=| procmail -v 2>&1 | sed '2,10d; s/^/       /'


LOG = "
      HOST is $HOST

      Version info is
$PROCV_OUT

"

The close-quote is purposely down below after a couple of newlines.

Here's what that looks like in my log when I run it:

      HOST is myhost5.myisp.com

      Version info is
       procmail v3.22 2001/09/10
       Locking strategies:      dotlocking, fcntl(), lockf()
       Default rcfile:          $HOME/.procmailrc
       Your system mailbox:     /net/u/1/d/dman/.mailspool/dman


Anyway, let that run on incoming mail, and see if it's the same
as when under your login shell with you feeding the test manually.


I want to know why. Can a sendmail patch applied to Solaris 9 affect 
procmail's regexp processing and/or scoring in any way?

Not that I've ever heard of or can imagine.



Here is a recipe that combines all of these ideas in one.  That is,
you don't need the first recipe that dev-nulled things that didn't
contain $LOCATIONS:

    :0 B  # inside brackets are a space and a tab
       *   ()\<$LOCATIONS\>
    * ! ()\<road[   ]+^?work\>.*(^.+)?(^.+)?^(.*\<)?$LOCATIONS\>
    deliver_me

 

What is supposed to happen if this recipe doesn't execute? In my 
procmail setup, the default at the end is to deliver to me 

The action line was just a throwaway.  Use whatever action line
you want.  What are you doing with success right now?  I don't have
your original email handy.  But this recipe was supposed to put
out the same thing as your scoring recipe and the previous one
that culled out non-$LOCATIONS, all at once.

inbox). So if this recipe executes, it delivers to me; if it doesn't 
execute, it still delivers to me. So this recipe really 
doesn't do anything.

Your recipes looked complex enough that I presumed you were a
fairly bright, computer-literate guy with a decent handle on
procmail.  So I just stuck an action in there that would be
recognized as such by all.  What you actually want for your
action line is up to you.

But below the recipe (which I didn't test, btw, but I think
it's close), you could put

        :0 E
        /dev/null

Since we were inside nested curly braces from your initial test for
mail from the traffic report, the `E' flag is not necessary, actually.

If you want to get fancier, you could just have underneath the
suggested recipe

        HOST

unsetting host and bailing procmail at that point with no more delivery.
That is slightly more efficient than the save to /dev/null.



This recipe still doesn't work. If the traffic report has an 
accident in Palo Alto and road work in Menlo Park, the recipe 
does not execute because the second condition is not satisfied. 
Then the subsequent recipe deletes the report that I wanted to see.

Well, as I said, I haven't tested it; but the logic I had in
mind should, indeed, work.  The negation (bang on the condition)
says that if we find a $LOCATIONS *not* within two (or was it
three?) lines of "road work", perform the action.  It won't
matter how many times a $LOCATIONS *is* next to "road work",
as long as there's one or more times when one *isn't*.

Try it and let me know!


I'll be impressed if anyone can accomplish the goal without 
scoring (and without invoking external commands/scripts). Anyone 
wanting to take on the challenge should test the proposed solution 
by subscribing to the traffic reports:
http://beta.kpix.com/news/traffic/mail/ .

I thought I took on the challenge already.  Let me know how I did.
If I didn't succeed, I'm close.  It's hard to get such a complex
regex syntax right the first time without any beta-testing, however,
so I won't be surprised if I didn't quite get it.

Dallman (ex-Bay Area boy, now in Germany)


-- 
"If you find a path with no obstacles, it probably does not lead to
anywhere."
        Thoughts of Rev. Sunnan Kubose, from _Zen in the Markets_ 



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail