Ian Zimmerman wrote:
[MATCH]
All the manpage says it this:
Some non-optimal and non-obvious regexps set MATCH to an incorrect
value. The regexp can be made to work by removing one or more
unneeded '*', '+', or '?' operator on the left-hand side of the \/
token.
<<
In procmailrc it says:
MATCH It will contain all text matching the regular expression past the ?\/?
token.
\/ Splits the expression in two parts. Everything matching the right part
will be assigned to the MATCH environment variable.
I don't see how my '*' is "unneeded", as removing it will change the
set of strings
covered (it won't match when there's no leading whitespace).
Sigh, you are not reading what I wrote, it is about ' *', not about '*'. You
are not reading technical texts like these in some silly proportional font,
right?
Let me try again: the expression ' *' (that is: space asterisk) in front of
the \/.* will match an empty string, because the expression after the \/ is
greedy.
In yet other words: ' +\/.*' is equivalent to ' \/.*'.
In PRE, the equivalent of procmail's '[$WS]*\/.*' is '\s*?(.*)', which is
better written as '(.*)'.
This is the good way to capture the contents of a header field:
Header-name:.*\/[^$WS].*
This is as RFC 822 says it should be:
Header-name[$WS]*:.*\/[^$WS].*
--
Affijn, Ruud
____________________________________________________________
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