Marc Weber wrote: > Today I tried this : > > cat -A /dev/zero | dd bs=1M count=1000 of=/dev/null; > > which does copy a different amount of data each time! > The new coreutils-7.1 does introduce the flag iflags=fullblock which > makes the line above copy 1G all the time as it should. > > However I really can't imagine any use case for the old default > behaviour not copying full blocks. Can you? > > so I consider this beeing a serious bug because you always have to learn > about iflags=fullblock and you have to remember using it. This is just a > waste of human resources.. > > If you tell me about some use cases I'll shut up immediately. > > I think that shell scirpting is such a high level that you should no > longer have to worry about this kind of stuff. If you really do you can > write your own personal dd for such use cases. > > So in my opinion there should be an error when using count=$COUNT and > less than $COUNT * ibs bytes have been copied.. > > So i'd make this fullblock be the default.
I agree that iflags=fullblock should have _been_ the default. However many scripts probably now depend on the current default of reading what's available. For example look at the test I added in the last few days to coreutils: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob_plain;f=tests/misc/cat-buf Also POSIX says stuff like: "If the input block is shorter than the specified input block size and the sync conversion is specified, null bytes shall be appended to the input data up to the specified size. (If either block or unblock is also specified, <space> characters shall be appended instead of null bytes.) The remaining conversions and output shall include the pad characters as if they had been read from the input." cheers, Pádraig. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
