Paul Eggert wrote: > Mart Somermaa <[EMAIL PROTECTED]> writes: > > >> - the implementation is simple, effective and 2^n/10^n-problem agnostic >> (at the cost of comparing 100000K less than 1M, which is not a problem >> as we assume the input to be properly scaled). >> > > That's the cost that I'm worried about. The input is not always > "properly scaled". Even GNU 'du' does not always "properly scale" > numbers in the sense that you're describing, since it sometimes says > "1001k" and sometimes "1.0M". I've never encountered such behaviour and IMHO it should be considered a bug (considering both the expectations of users and the column widths in 'du -h' and 'df -h'). Can you provide a test case? > In general, if sort ignores the > distinction between powers-of-2 and powers-of-10, the output will be > wrong sometimes. > But do you agree that if the assumption of properly scaled input holds, the output is always correct? So it all boils down to proving that the assumption does not hold for other coreutils. For other applications -- it's a documented limitation after all.
It is really just a convenience feature, so if you don't see it as a useful contribution, let's drop the discussion. I'll go on patching coreutils for my very own sort :) . But let me point out that it has been valuable for me in handling everyday tasks and I have not yet encountered incorrect behaviour with 'du' or 'df'. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
