Hi,
In the past, the "dd" program would report the number of records
copied when it stopped. dd stopping can of course be caused by
several things: Running out of input, input IO error, output
io error, or the case of interest here, the output pipe getting
closed.
Someone has quoted the standard to say:
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).
and as dd recieves a "SIGPIPE" when an output pipe is closed,
this was interpreted as: in that case dd is NOT ALLOWED to print
any statistics output.
In my case, I used the "dd" program as an intermediary in a pipe, and the
statistics output was used to get a rough (how much data
was already in the pipe buffer is unknown) estimate of the amount
of data copied. The new "claimed-to-be-compliant" dd no longer outputs
the amount of data copied, resulting in failure of the script.
This is of course the opposite of the intent of a standard....
My questions are these:
Is the standard indeed intended to "silence" dd in case of the output
being a pipe, and the reading end of the pipe being closed?
If so, what arguments are used to support such a decision? It is imho
very odd that dd would report the amount of data copied for almost all
situations except when the output happens to be a pipe, and the
reason for stopping happens to be the output being closed.
Is there any historical "dd" that would behave like this, where the
standard would describe it's behaviour, to standardise this behaviour
for compatiblity reasons?
Best regards,
Roger Wolff.
P.S. It's the FSF coreutils maintainers that apparently interpret
the standard this way, and modified their version of dd to no longer
report the statistics in this case. (claiming standards-compliance
as the reason for the change) This caused a script I wrote
to fail. I am not interested in getting my script to run again.
It already does: I wrote a simple subset of "dd" to simply report
the number of blocks copied, even in the case of the output
pipe being closed. I'm interested in this subject to make the
standard "work as intended": to increase interoperability. My,
and other people's scripts should keep on working across platforms
and versions, instead of requiring manual fixups after each update.
--
** [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]