Re: dd's reaction to a close of the output. (debian Bug#461049)

[Paul Eggert]

Following up on Debian bug 461049
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461049>,
Nick Stoughton <address@hidden> writes:

> Note that last paragraph ... I believe that this does give dd permission
> to report its statistics on SIGPIPE.

It certainly does.  Wow.  That "perform some additional processing"
loophole is big enough to drive a truck through, though; as worded it
would let dd (say) execute "rm -fr $HOME" on receipt of SIGPIPE.

Surely there was intended to be _some_ limit on the "additional
processing" that utilities can do when they receive a random signal.
I would think that the intent was that this "additional processing" be
limited to cleanup actions (e.g., remove a temp file, or perhaps
restore the terminal state).  Printing statistics goes a bit beyond
that, and one could easily argue that it goes beyond what the standard
was intended to allow.

> Few of the systems that I have tried this on do produce statistics under
> these conditions. Those that do are running some old core-utils
> implementation of dd!

In 2005 I submitted the patch to coreutils dd to make it treat SIGPIPE
like all other known dd implementations do.  This was partly motivated
by my interpretation of POSIX, but it was also partly because I
couldn't see a good reason why coreutils dd would be incompatible with
all other dd implementations I knew of.

There is a similar issue with SIGQUIT, by the way.  Pre-2005 coreutils
'dd' treated SIGQUIT like SIGPIPE: that is, it printed statistics
before killing itself with SIGQUIT.  I don't view this as being
standard behavior either.