James McGill wrote,
| That brings up what I feel is the one thing that I'd like to see in a
future
| version of procmail. The ability to delimit multiple MATCH's in the manner
| of /(.*)(.*)/$1$2/ syntax. As it happens, it is Match to End, which is
| useful, but not as flexible as it could be. (You can only match one thing,
| and only to the end of the regexp.)
One can extract the entirety and then extract pieces from there; it's not
as convenient as what James proposes, but with sufficient circumlocution it
can be done.
That's the point, David: I shouldn't have to "circumlocute" procmail, I
want to use it to increase *my* email productivity and efficiency.
Computers should do more work, not humans.
There is usually a correlation between generality and complexity:
increase the generality of an algorithm, and its complexity usually
increases by some measure also, and, as complexity increases, the
computer performance and efficiency decreases.
So what if the computer has to work a little harder because its regular
expression engine is a tad more general and a bit less efficient? With
that little bit of increased generality, I can more easily write
regular expressions to parse strings *within* procmail, which avoids my
having to invoke grep, sed, or awk at various times.
I'm not saying that procmail needs all of Perl's bloat -- if I thought
that, I'd write a Perl module which fulfills procmail's and formail's
functions of address header munging and such, and write my mail filters
in Perl. I like procmail's efficiency and lightness--I just think that
a more powerful regexp parser would go a long, long way to making
procmail recipes even more versatile at minimal cost.
___________________________________________________________
Alan Stebbens <aks(_at_)sgi(_dot_)com> http://reality.sgi.com/aks