Liviu Daia <Liviu(_dot_)Daia(_at_)imar(_dot_)ro> writes:
On 27 February 2000, Philip Guenther <guenther(_at_)gac(_dot_)edu> wrote:
...
What do you mean by "crash after consuming the input"?
Any abnormal death, f.i. from a signal. Should it die before it
gets to read all the input, the calling Procmail would get a SIGPIPE...
When a program dies from a signal (say, SEGV) the parent only finds
out if it checks the exit status.
Exit status != return code. What exactly happens if you leave out
True: return-codes are a proper subset of exit statuses. The exit status
obtained via the wait() system call encodes the reason the child process
is gone, be it a normal exit via the _exit() system call or death by
signal, and the value associated with that reason, either a return-status
or a signal number.
the "w" and "W" flags? Procmail simply produces a zombie? Or it does a
fork + setsid in order to avoid the zombie?
Procmail doesn't avoid the zombie by double-forking. It just puts off
the wait() till the next time it needs to wait for child. It'll then pick
up the other child while it's at it. Of course, the filter won't return
before the child process is gone unless it explicitly closes its stdout.
If a child process does that, and the filtering recipe doesn't have the
'w' or 'W' flag, procmail will consider the action finished and go onto
the next recipe.
So, that bottom right-hand box should be "happily keeps the filtered
message".
Sorry, but I wouldn't have dreamed that in my worst nightmares.
This is rotten. What's the point in having a flag if it's never safe to
leave it out?
I'm not particularly happy about this design choice either, but I haven't
seen any easy way to change it without breaking something. You appear
to be suggesting above that procmail *always* wait for the child process
to die, regardless of the flags, and then always treat death-by-signal
as failure. Hmm, that has possiblities...
I've set replies to go to procmail-dev.
Philip Guenther