David W. Tamkin wrote:
...
James Waldby wrote,
...
| Do you have a reasonable explanation for anchoring with ^^ ?
1. To make it clear to the reader that we're starting from the beginning of
the body, but more importantly,
2. To squirm out of the leading backslash problem. ()\/ would have done that
too, but ^^\/ also takes care of #1.
| In some tests I ran via "formail < mmm -s procmail"
| with a batch of 8 messages in mmm,
| * ^^\/.*$?.*$?.*$?.*$?.*$?.*$?.*$? matched all 8 messages but
| * \/.*$?.*$?.*$?.*$?.*$?.*$?.*$? only matched 6 of them.
...
The actual reason for the
difference is that your second condition falls afoul of the leading backslash
problem. An opening backslash in a condition means "no more leading white-
space or modifiers to strip; this is the start of the regexp."
...
So \/ with nothing to the left of it means "one foreslash".
...
If \/stuff matched only six of the eight messages, only six of them con-
tained "/stuff". Try these instead and see if they match all eight:
* ()\/.*$?.*$?.*$?.*$?.*$?.*$?.*$?
or
* \\/.*$?.*$?.*$?.*$?.*$?.*$?.*$?
Yes, the ()\/.*$?etc and \\/.*$?etc patterns match all of the messages.
And of course it turned out that the two messages that didn't match the
\/.*$?etc pattern had no / in the message body, and of course "*
\/.*$?"etc left $MATCH unchanged.
Now, one more question. With following in .procmailrc :
:0B
* ^^\/.*$?.*$?.*$?
{ LOG=" a |$MATCH| a " }
:0B
* ()\/.*$?.*$?.*$?
{ LOG=" b |$MATCH| b " }
:0B
* \\/.*$?.*$?.*$?
{ LOG=" c |$MATCH| c " }
after the command "formail < mm -s procmail" with one message in mm
with a message body that begins:
L1
L2
L3
L4
the log file said
a | L1
L2
L3| a b | L1
L2| b c | L1
L2| c
which means, after \/.*$?.*$?.*$? $MATCH was first three lines of body,
but after ()\/.*$?.*$?.*$? or \\/.*$?.*$?.*$? patterns, only first two
lines.
Why?