Subject: Re: formail -s not closing stream

From: [email-masked] (Stephen R. van den Berg)
Date: Fri, 11 Feb 1994 13:16:45 +0100

Sam Jam <[email-masked]> wrote:
>When I do formail -s xxxxx

>where xxxxx is a stream e.g.
>
>sed zzzzzzzz | massmail yyyyyy

>and sed is a bit slow, I find that the next piece of mail is put into
>the SAME invocation of sed, all my mail gets jumbled into one file
>whuch massmail gets.

>less, the problem becomes clear, and it is obvious that less is getting
>more than one file.

>Does this sound likely?

Honestly, no :-).
I really close the descriptor before waiting and forking the new sed.
Maybe you don't quite understand what is going on.  If there are three
mails in the file mbox and you start things like this:

	formail <mbox -s sed zzzz | massmail yyyy

Then, the following will happen:

	formail --+--mail1---> sed ---+---> masmail
	          +--mail2---> sed ---+
	          \--mail3---> sed ---/

I.e. formail will start a new instance of sed for every mail.  Since masmail
is being started by the shell (and not by formail), there will be only
one instance of masmail collecting the output of all seds.

As is, formail will make sure that the seds will output their mail in a
serialised way (i.e. the mails will not intertwine).
If you give formail the -n option (nowait), then formail will fire off
the seds as soon as possible.  With the result that the output of the
seds might interleave each other.  This interleaved output is then
read by one masmail process.

To fix it, simply make sure that both sed and masmail are started anew
by formail for every mail.  Encapsulate both in a shell script so that
formail starts the shell script instead.  Or, from the command line:

	formail -s sh -c 'sed yyyyyy | masmail zzzzz'

-- 
Sincerely,                                  [email-masked]
           Stephen R. van den Berg (AKA BuGless).

Real programmers don't just die, they produce core dumps.