Martin Mokrejs <mmokrejs(_at_)natur(_dot_)cuni(_dot_)cz> writes:
On Thu, 16 Mar 2000, Ralph Seberry wrote:
:0 H
* ^Subject:[ ]*BOUNCE.*Non-member.*submission.*from.*\[\/[^\]]*
{
ODESILATEL="$MATCH"
LOG="Odesilatel1 je $MATCH
"
}
(instead of ".*", tell it to get all characters up to ']' by using "[^\]]*")
Hmm, procmail says it matches but the variable is empty.
How does the \/ work? Does the match contain everything on the right side
from \/ or everything on the right side from \/ untill "[^\]]*" is
reached?
As also pointed out by Liviu Daia, the correct expression for mathching
zero or more non-close bracket or newline characters is
[^]]*
Could someone please shed a light on these following recipes? Especially,
meaning of plus at the end, the scoring example reading Delivered-To:
field ...
The '+' regexp operator is similar to the '*' operator except the
operated on regexp term must match at least once. '*' is zero or more,
'+' is one or more.
:0 # why do we need $ on the next line, where is variable expansion?
*$ ^Subject:[ ]+\[.*\][ ]+\/.+
| formail -I"Subject: $MATCH"
The '$' on the condition is unneeded because there are no variables or
command substitutions in the line. Also, because of procmail
minimal/maximal matching, it won't trim all of the whitspace before the
main text of the subject unless it is written as:
* ^Subject:[ ]+\[.*\][ ]+\/[^ ].*
Please read era's mini-FAQ for details:
http://www.iki.fi/~era/procmail/mini-faq.html
:0 # here we need $ on the next line to expand $TAG variable, am I right?
* $ ^Subject:(.*\<)?$\TAG\>
Yes.
...
And finally, to my problem:
# why doesn't he recipe match this string:
# ["David Silhan" <silhand(_at_)feld(_dot_)cvut(_dot_)cz>] (fwd)
# I want to extract "David Silhan" <silhand(_at_)feld(_dot_)cvut(_dot_)cz>
* MATCH ?? \[\/[^]].*
The log file shows:
procmail: Skipped "* MATCH ?? \[\/[^]].*"
There are two problems here. The main problem is that you can't just
put a condition line in the middle of nowhere. You need to start a
recipe with the ":0" line, then your desired conditions, and then an
action line.
The other problem is that procmail interprets a leading backslash on the
regexp part of a condition as an attempt to disable special
interpretation of conditions specials like '$', '<', '>', and '!', so it
strips it before compiling the regexp. The above regxp is thus read as
[\/[^]].*
which will match
exactly one of the following \ / [ ^
then a ]
then any number of non-newline characters
You can prevent this special interpretation by placing an empty pair of
parens before the backslash, such that it is no longer the first
character of the regexp:
* MATCH ?? ()\[\/[^]].*
You can also escape it by doubling the backslash, but this is considered
more confusing to read:
* MATCH ?? \\[\/[^]].*
so don't do that.
Philip Guenther