When I wrote,
| > ... the question left open is what to
| > do when you *want* a leading newline in $MATCH. I can't think of a
| > situation where anybody would ...
Ed Sabol responded,
| Hello? Remember the line-by-line processing thread three weeks ago that
| brought the whole problem of the leading newline being stripped from $MATCH
| into the light?
I remember the thread but not every fiber of it. The times I've written
recursive line-by-line code for a procmailrc I *have* wanted to skip empty
and blank lines and have made sure that the extracting regexp included
"\/[^ ]".
| :0B
| * $ < ${LINEBUF}
That will measure the entire text; size conditions ignore H and B flags. The
way to measure the body alone is
* $ B ?? < $LINEBUF
| By the way, here's a patch that gets rid of stripping the leading newline
| from $MATCH entirely (I haven't tested to see how this affects putative
| newlines, but for my applications it works fine since I usually put the match
| operator after "^^"):
|
| *** regexp.c Fri Nov 7 16:15:01 1997
| --- regexp.c.new Fri Nov 7 16:17:36 1997
| ***************
| *** 598,605 ****
| tmemmove(q=(char*)text,bom,len),q[len]='\0',bom=q;
| else
| { char*p;
| - if(*bom=='\n')
| - bom++; /* strip one leading newline
*/
| primeStdout(amatch);p=realloc(Stdout,(Stdfilled+=len)+1);
| tmemmove(q=p+Stdfilled-(int)len,bom,len);retbStdout(p);
| }
| --- 598,603 ----
Thanks, Ed. Anyone brave enough to try?