On Tue, Jan 29, 2008 at 03:33:01PM +0100, Jim Meyering wrote:
> Rogier Wolff <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 29, 2008 at 01:27:57PM +0100, Jim Meyering wrote:
> >> Rogier Wolff <[EMAIL PROTECTED]> wrote:
> >> ...
> >> > Let me reiterate: It is the first "dd" that is misbehaving, when it
> >> > recieves a write error and SIGPIPE, it simply exits instead of
> >> > reporting the stats.
> >>
> >> Thanks for the report, but that behavior is required by POSIX.
> >> dd must handle SIGINT the way you want, but dd may not handle
> >> SIGPIPE that way:
> >>
> >> ASYNCHRONOUS EVENTS
> >>
> >> For SIGINT, the dd utility shall interrupt its current processing,
> >> write status information to standard error, and exit as though
> >> terminated by SIGINT. It shall take the standard action for all
> >> other signals; see the ASYNCHRONOUS EVENTS section in Section 1.4
> >> (on page 2280).
> >
> > Please interpret it as dd is supposed to work:
> >
> > Please block the "SIGPIPE" signal, then write will return:
> ...
> > If you start "waving standards around", I'll bounce it back for you.
>
> You're beating a dead horse already.
> You'll need to come up with much better arguments (that probably
> do not exist) to make me change dd to be non-compliant in this respect.
In my interpretation of the quoted part of the standard, dd has become
non-compliant, by not reporting the statistics when its output happens
to be connected to a pipe.
I will agree that my interpretation is a bit convoluted. But it's a
valid interpretation, and it makes dd do the "sensible thing".
It currently implements a "weird" exception, fuelled by a litteral,
interpretation of unintentional wording in a standard.
I'm all in favor of standards. However, blindly implementing an
unintentional consequence of a standard is not the way to improve
interoperability.
The INTENT of the that part of the standard was to say that dd
implementations need not catch-and-handle all possible signals.
If any other dd can be found that behaves like gnu-dd does now, which
warrants gnu-dd to comply to an unintentional consequence of some
interpretation of the standard, I'll concede.
If any other user can be found who is surprised by dd outputting the
stats after the output pipe is closed (but not when the disk is full
or any other error), I'll concede.
The current situation is simply blindly mis-interpreting the intent of
the standard, and then blindly implementing that.
If you would argue that you need to point out the sillyness of the
standard to the standards commission by literally implementing it,
fine, you have my support.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
