At 20:19 2002-07-03 -0500, Philip Guenther wrote:
I assuming you meant
:0
BODY=|formail -I ""
Actually, no it wasn't, but the answer provided was equally useful to
anyone reading.
After running a couple of tests though, I realize that the pipe-n-tick
version of my standalone assignment does in fact dump a pipe in the
beginning of the variable assignment, so the original question is moot.
Having myself pointed out that it required that sort of invocation
elsewhere in my message, yes I would have meant to include that had I been
presenting THAT style of variable assignment.
The main difference is that the straight variable assignment is subject to
the LINEBUF limitation, while the variable-capture recipe version isn't.
LINEBUF for the WHOLE variable, not just individual lines of it? So a body
in excess of LINEBUF (which would be pretty easy to manage), would screw
things up? Yikes, and to think that the capture recipe version has
problems in 3.22...
In my mind, the tic'd command is a capture of the output, so it'd be a
capture too. However, you mention recipe specifically, so I'll take it to
mean the piped one. So procmail actually expands the tic'd commands within
the parser, not straight into the assignment? Can this be exploited to
create regexps right on the condition line, or is the line parsed only once?
The 3.22 problem with:
:0
BODY=|formail -I ""
or even:
:0b
BODY=|cat -
reared it's head on the test machine on which I run 3.22 (due to unresolved
bugs, I stick with 3.15.2 on my production systems, and just run 3.22 on a
test host).
Is the memory problem resolves in 3.23 beta, and if so, what is 3.23
waiting on?
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail