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]