Re: dd or other bug?

[Pádraig Brady]

Paul Eggert wrote:
> Pádraig Brady <address@hidden> writes:
> 
>> dd does not issue another read() request to fill the input buffer,
>> before proceeding with the write(). I'm not sure why it does this.
> 
> Because that's the way it's always done it.  :-)
> 
> Anyway, POSIX requires this behavior.  See
> <http://www.opengroup.org/susv3/utilities/dd.html>.
> 

Thanks very much for the link. I searched for "short" in that,
and what you say appears to be the case. It states there:

"The data resulting from input or conversion or both shall be aggregated
into output blocks of the specified size. After the end of input is reached,
any remaining output shall be written as a block without padding if conv=sync
is not specified; thus, the final output block may be shorter than the output 
block size."

Now the original poster specified "bs=32768" to the second dd.
That implicitly sets the output block size to 32768.
So shouldn't the short reads be aggregated to the implicit output block size.
Well no according to the description of the bs option:

"Set both input and output block sizes to expr bytes, superseding ibs= and obs=.
If no conversion other than sync, noerror, and notrunc is specified, each input 
block
shall be copied to the output as a single block without aggregating short 
blocks."

That's clear. So that suggests that if both ibs and obs are specified it may 
work.
However count=1 was also specified and according to the spec that means,
"Copy only n input blocks". Note "blocks" in the spec refer to what was read
not what was asked to be read.

So according to the spec the only way to do what the original poster required
is to do inefficient 1 byte reads like: dd count=32768 ibs=1 obs=32768

I wonder should we add an option to aggregate short reads up to ibs?

Pádraig.