Udi wrote,
On Tue, 4 Nov 2003, David W. Tamkin wrote:
I have no problem with "H"
Some versions of procmail do. Put an `H' flag on a recipe and it sticks
until procmail exits, turning all your `B' flags into `HB'. `H' without
`B' is the default anyway. Unfortunately, the `H' also sticks if you
need `HB'. When you need `HB' with one of those versions, you have to put
HB ??
onto the individual conditions instead to avoid triggering the bug.
and I do braces in my procmailrc
to make it easy to read. Is it more then styll problem?
It's wasteful to make procmail read extra text and keep track of an
additional nesting level. If there's ever a good reason to do this,
:0 #no conditions
{
code in here instead of out there
}
I'd love to see an example.
I suggested,
>> # each pair of brackets encloses space and tab
>> * ^Subject:.*out[ ]+of[ ]+the[ ]+office
Udi replied,
> The following recipe will do the matching and you will be able to
> send the message to folder, but, it will not assign the matched
> string into variable.
> :0
> * ^Subject:.*Out([ ]|$)of([ ]|$)the([ ]|$)Office
> { SUBJECT=$\MATCH }
Udi,
1. You left the plus signs out, but I see from the log excerpt that you
had them in your actual recipe.
2. You have no extractor ("\/") in there, so that's why MATCH did not
get assigned and $\MATCH was just an empty pair of parentheses.
4. "$" for a newline won't match anything in the interior of a header
line, because procmail does not recognize header continuation newlines
as newlines.
Meanwhile, I did some experimenting, and if $variable includes an
embedded newline, $\variable will not escape it, but if you have this
condition,
* $ $\variable
procmail will treat the embedded newline as a literal character. Thus,
var="new
line"
* $ $\var
expands to
* ()new^line
where the caret represents an embedded newline to procmail, of course.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail