Paul Eggert wrote: > Mart Somermaa <[EMAIL PROTECTED]> writes: > > >> 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? >> > > It's not a bug. Here's a test case. > The size of 'big' is 2**40 - 2**30 bytes, and 'bigger' is one byte bigger. > > $ ls -l big bigger > -rw-rw-r-- 1 eggert faculty 1098437885952 2006-05-31 10:20 big > -rw-rw-r-- 1 eggert faculty 1098437885953 2006-05-31 10:20 bigger > $ du -h --apparent big bigger > 1023G big > 1.0T bigger > Everything is as expected (input is still properly scaled) in this case, as powers of 2 are involved. Hence 1023G < 1.0T holds and my code works correctly:
echo -e "100M\tsmall\n1023G\tbig\n1.0T\tbigger" | ./sort -h 100M small 1023G big 1.0T bigger _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
