procmail
[Top] [All Lists]

Re: LINEBUF questions

2001-08-24 20:14:45
On 24 Aug, David W. Tamkin wrote:
| Don Hammond asked,
| 
|| 1. Can LINEBUF be adjusted in either direction?  Such as:
||
|| LINEBUF=8192
|| :0
|| { Recipe }
|| LINEBUF=2048
| 
| Yes, absolutely.
| 
|| 2. If the above is not meaningless, is anything gained or lost?
| 
| Assuming your system can spare the extra memory for the longer line
| expansions that you are now allowing, something could be gained and it's
| unlikely anything would be lost.  However, be sure you're done with those
| lines that have long expansions before you lower LINEBUF to its previous
| value.

Thanks David. I did some tests also, and there's no noticeable effect on
memory use, though I suspect 2048 -> 8192 isn't at all significant until
the mail volume is considerably higher than mine. It would certainly
need to be more than what I gave it in these tests. There were a couple
other interesting things (to me anyway :-).

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­
       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­
       tinue  processing.   If  it  is  a  variable assignment or
       recipe start line then procmail will abort the entire  rc­
       file.

It's probably my misunderstanding, but seems a better outcome anyway.
Also PROCMAIL_OVERFLOW is not set in this case.

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.

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.

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?)

Thanks again for the help.

- 
                   /"\
Don Hammond        \ /     ASCII Ribbon Campaign
Raleigh, NC US      X        Against HTML Mail,
                   / \      and News Too

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>