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]

Reply via email to