On 25 February 2000, Bennett Todd <bet(_at_)rahul(_dot_)net> wrote:
2000-02-25-14:53:59 Liviu Daia:
:0 Bfh
* H ?? ! ^Lines:
* -1^0
* 1^1 ^.*$
|formail -A "Lines: $="
Cool! I _love_ these things, it's like doing cryptograms, or trying to
decypher Intercal.
Actually, this is my favorite reason for still being subscribed to
this list. :-)
[...]
This should work, right? Well, I've been happy with it for years,
until I discovered that it counts one too _many_ lines. Any idea
what's going on here?
If it counts one too many, I can only guess that you're wanting to
leave off both the empty line that separates the header from the body
and also the empty line that's appended to messages to make sure mbox
separating "From " lines always have blank lines preceeding them.
Well, the reason I'm adding a "Lines:" in the first place is to make
life easier for my MUA when splitting mbox folders into messages. Both
the mailer I'm using now and Mutt (that I used a while back) can make
good use of this hint --- provided the count is correct. However, they
both expect a message produced by
mail daia </dev/null
to have a "Lines: 0", and one sent with
echo | mail daia
to have a "Lines: 1", while the recipe above produces "Lines: 1" and
"Lines: 2" respectively. If Procmail is counting the header separator,
this didn't use to happen before, as David pointed out.
In which case you might be happier with the results if you changed
"-1^0" to "-2^0"?
Yes. My question was not how to fix it though, but why does it
happen.
[...]
:0 Bfhw
* H ?? ! ^Lines:
* 1^1 ^.*$
|formail -A "Lines: $="
Isn't it better kharma to add a "w" to filter statements, so if the
called program finds some way to bomb procmail won't replace the
message header (in this case) with the presumably failed output?
[...]
Well, the way I understand it, the only use for "w" here would be to
provide a return code for a subsequent ":0 e" recipe, which is something
I don't have right now.
On 25 February 2000, David W. Tamkin <dattier(_at_)mcs(_dot_)net> wrote:
[...]
Even after -1^0 it still counts one line too many? Or are you asking
why it needs the -1^0? The former baffles me; the latter I can
answer.
It's the former. See the two examples above.
[...]
So when you are counting lines with 1^1 ^.*$, procmail keeps backing
up one byte so that it can reuse the newline that was the previous
line's $ as the current line's ^. Finally, at the last line, it
matches the newline at the end of it to $. But then it backs up and
matches
<closing real newline><nothing><putatitve newline> to ^.*$ and counts
one line too many.
Now, Liviu, if you knew all that and your question is why procmail is
still counting one line too many even after -1^0 and you're going to
have to change it to -2^0, then I'm baffled.
Well, after reading this list for so many years, I had the occasion
to see you and Phillip offering this explanation a few times. :-) It's
weird enough to prevent me from forgetting it. Unfortunately, yes, it
appear to be what happens here.
As to Bennett's theory that it is counting the blank line between the
head and the body, it never did before; has that changed, Philip? Or
are you suddenly receiving mail that has two blank lines between the
head and the body, such that the second one is legitimately part of
the body but you don't want to count it?
Hmm. That last one can be tested for easily. Try this:
:0fh
* ! H ?? ^Lines:
* B ?? ()\/.+$(.*$)*
* 1^1 MATCH ?? ^.*$
* -1^0
| formail -A "Lines: $="
Hmm. With this recipe both
mail daia </dev/null
and
echo | mail daia
don't match (as expected), while
echo 1 | mail daia
still produces a "Lines: 2". I'm equally baffled.
Regards,
Liviu Daia
--
Dr. Liviu Daia e-mail: Liviu(_dot_)Daia(_at_)imar(_dot_)ro
Institute of Mathematics web page: http://www.imar.ro/~daia
of the Romanian Academy PGP key: http://www.imar.ro/~daia/daia.asc