David W. Tamkin wrote:
...
Absolutely (actually, ^^(.*$)\{0,49\}.*pattern for Adam's question). ...
it might actually save CPU cycles as well as brain cycles
to suck the stuff into a variable with head once and for all.
And even then we can do this,
:0B
* ^^\/(.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$)?\
(.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$.*$)?\
(.*$.*$.*$.*$.*$.*$.*$.*$)?(.*$.*$.*$.*$)?(.*$.*$)?(.*$)?
{ toplines=$MATCH }
and then
* w^x toplines ?? pattern
in subsequent recipes.
I think .* would be good enough at the end there, instead of (.*$)?
-- possibly a case where "that trailing .* is [not] a waste"
Do you have a reasonable explanation for anchoring with ^^ ?
There is an efficiency-and-correctness issue if * ? + being greedy to
the right of \/ allows procmail to look anywhere in the search area,
but under a constraint to find the first match and make that match as
long as possible, ^^\/.*?.*? ought to give the same result as \/.*?.*?
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.