Don Hammond <procmail1(_at_)tradersdata(_dot_)com> writes:
...
Without changing LINEBUF,
LONGVAR=`perl -e'print "x" x 4000;'` gives (not surprisingly):
Excessive output quenched from "perl -e'print "x" x 4000;'"
LONGVAR is truncated (to 2039 bytes) as would be expected from the
documentation. But procmail continued processing the rcfile which is
not the way I read the procmailrc man page.
A line buffer of length $LINEBUF is used when processing
the rcfile, any expansions that don't fit within this lim\xAD
it will be truncated and PROCMAIL_OVERFLOW will be set.
If the overflowing line is a condition or an action line,
then it will be considered failed and procmail will con\xAD
tinue processing. If it is a variable assignment or
recipe start line then procmail will abort the entire rc\xAD
file.
It's probably my misunderstanding, but seems a better outcome anyway.
Also PROCMAIL_OVERFLOW is not set in this case.
Heh. That's because the "pipe through" code used by command (backquote)
expansion has had 'overflow' checks predating the generic overflow
checks. It's certainly a better outcome, but it should still set
PROCMAIL_OVERFLOW. Hmm, that's easy to fix. Version 3.22 will set
PROCMAIL_OVERFLOW in this case too.
Using a message with a 3000 character To: header and doing:
:0
* ^To: \/.*
{ LONGVAR="$MATCH" }
gives error: Exceeded LINEBUF, and in this case LONGVAR is either
unassigned or retains any previous value and PROCMAIL_OVERFLOW=yes.
Again, the rcfile continues to be processed.
I guess I need to recheck the exact circumstances that'll cause procmail
to give up an rcfile on overflow and update the manpage.
Repeating the recipe just above with LINEBUF=4096, then immediately
resetting LINEBUF=2048, still allows me to use LONGVAR in later recipes.
I did confirm that the buffer was reset to the smaller size, and
following it with a condition like * LONGVAR ?? x^^ works fine. That
surprised me a little, but nicely. In fact, matching it against
something on the right side that complains "Excessive output
quenched..." still works too.
As you've found, changing LINEBUF doesn't change any variables that are
already assigned. It's the size of the expansion buffer, not a limit
on variables. Matching against a variable with "var ??" doesn't expand
the variable.
Finally, something like:
:0 w
LONGVAR=|formail -zx To:
avoids the whole LINEBUF issue entirely. I saw this in one of Philip's
messages in the list archive but didn't see it in the man pages. So out
of curiosity, as someone who is conscientious about avoiding unecessary
resource use, which poison whould you choose? The extra formail
process, or the temporary increase to LINEBUF? (Or don't care?)
Increasing LINEBUF is cheaper.
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail