procmail
[Top] [All Lists]

Re: error in recipe

2005-01-11 16:23:25
I'll respond to various of Ruud's message together.

On Tue, Jan 11, 2005, Ruud H.G. van Tol wrote:

Toen wij Dallman Ross kietelden, kwam er dit uit:

Whoa, wait a minute, here's another idea:
  REM = '!$ ^^^^ ${-$myrem} ^^^^ !
'

Yes, that is a nice 'unmatchable'. Unless somebody 
receives an e-mail with a matching header...

Well, it would be hard (impossible) to be a header field, since
there's no colon in it and I started at the top boundary of the
headers with the ^^ anchor; and anyway, the ^^ that comes next
means the end of the area, so the header would have to be
blank, I think, for ^^^^ to match something.  If the recipe
has a B-flag up-top, there's a slight possibility of a
match, though, theoretically at least.  But see down below
about that.

Meanwhile, I should add here before I forget, that after
I turned off my computer last night it occurred to me that
I don't need the curly braces at all.  That's exactly
the same as 

      REM = '!$ ^^^^ $myrem ^^^^ !
      '

For those baffled by the syntax, I should explain.  First, it's just a
fancy variable assignment.  The hard quotes mean that the value will not
get expanded with only the typical procmail "$" expander used in the
condition.  We'd need two dollar signs, to recurse twice with expansion
over the var.  That's the part that allows us to restate the value of
$myrem ex-post-facto and still have the new value show up.

However, I put the second dollar-sign expander inside the var itself.
The first pass through with a condition line --

   * $ $REM

the internal dollar sign gets read and it, magically, expands the
$myrem part.   The rest didn't need expanding anyway.

Continuing, the ! is standard procmail negation.  The ^^^^ is "^^"
start-of-area-being-evaluated (usually the top-left of the header,
unless a B flag has been applied up-top), followed by the end of the
area being evaluated (the bottom-right of the header -- or, if the B or
BH flags were used on the recipe, then the end of the body).

The rest, except for the $myrem that will be expanded on the second
pass via the internal dollar sign, is just textual chars.

In light of the lack of control we have depending on whether there
was a B flag at the top of the recipe in question, I want to
emend the string.  See below.


The match on '^^(message)?' is safer & faster, I presume.

I don't see the above as less safe, though, as explained.  If
you disagree, please expound.


Alternative:

  REM = ' $ ^^ * * *($myrem)* * *'

or even:

  REM = ' $ ^^ * * *($myrem)* * * ^^'

(will give a 'No match on', but who cares.)

But wait a minute: if it gives no match, then the recipe
fails!  Right?  You need the last asterisk to abut the end
of the string.


 procmail: Match on "^^* * * *(Kilroy was here)* * * *^^"


These are close to my original, except that I had
a question mark after the close-paren to make it as
utterly efficient as possible.  But sacrificing a
question mark for an asterisk is okay, and gives us a
cleaner look, yes.  Here's another syntax I came up
with after posting last night with the negation:


  REM = '!$ ^ ! ^ ! ^ ! $myrem ! ^ ! ^ ! ^ !'

Result from that in a log:

 procmail: Match on ! "^ ! ^ ! ^ ! Kilroy was here ! ^ ! ^ ! ^ !"

However, the double-caret anchor is better for procmail.  So
we could do it your way, as emended by abutting the last
asterisk against the trailing ^^.

  procmail: No match on "^^* * *( Kilroy was here )* * *^^"

Or:

 procmail: Match on "^^* * * * * *[ Kilroy was here ]* * * * * *^^"

which  I really like the look of the output of.

Okay, here's the _pièce de résistance_:

  REM = ' $ H ?? ^^* * * * *[ $myrem ]* * * * *^^'

I added an H flag!  Now we don't need to worry about what
flags might be up-top on this recipe.  (Later: but now
I see your use of $HOST below to do the same, only with even
more of an improvement.  Oh, well.)


=::::::::::::::::::::::=

Toen wij Ruud H.G. van Tol kietelden, kwam er dit uit:

  REM = ' $ ^^ * * *($myrem)* * *'

That one goes wrong when there is a ')' in $myrem. But a $\myrem will
create a () in front.

Still maybe a safe default:

  REM = "${REM:-\$! ^^^^ * * *( \$\myrem )* * *^^^^ *}"

What about the brackets above, then?  With that, parens work
fine in $myrem.  We can't have a "]", however.


=::::::::::::::::::::::=

Toen wij Ruud H.G. van Tol kietelden, kwam er dit uit:

Still maybe a safe default:

  REM = "${REM:-\$! ^^^^ * * *( \$\myrem )* * *^^^^ *}"

Or maybe something along the lines of :

  REM = "${REM:-\$! HOST ?? ^^^^ \$\myrem ! <--- }"

(because HOST is a smaller buffer to test against)


Hmm.


=::::::::::::::::::::::=

Toen wij Bart Schaefer kietelden, kwam er dit uit:

This all seems like rather a lot of hoops to jump through.

There are known advantages to log-lines that have predictable starts
and/or endings, like their better grep-ability.

And I prefer a syntax like:

  :0

  *$ $REM message { }

which can be achieved with

  REM = "! HOST ?? ^^^^${TAB}"


Yeah.  Bart has a good point, though, of a KISS (keep it simple,
sucker) variety.  Still, this has been fun, and I'm going to
implement the improvements.  I think I'll go with 

  REM = ' $ EXITCODE ?? ^^* * * * *[ $myrem ]* * * * *^^'

because $EXITCODE is usually empty or only one or two chars in length;
and I'll remember not to put a "]" char in $myrem when I assing it.

  MYVERBOSE = $VERBOSE VERBOSE = off
  REM = ' $ EXITCODE ?? ^^* * * * *[ $myrem ]* * * * *^^'
  VERBOSE = $MYVERBOSE

-- 
dman

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail


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