[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Support bytesize comparison in sort
From: |
Mart Somermaa |
Subject: |
Re: Support bytesize comparison in sort |
Date: |
Fri, 02 Jun 2006 19:52:01 +0300 |
User-agent: |
Thunderbird 1.5.0.2 (X11/20060522) |
Paul Eggert wrote:
> Mart Somermaa <address@hidden> 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
- Re: Support bytesize comparison in sort,
Mart Somermaa <=
- Re: Support bytesize comparison in sort, Mart Somermaa, 2006/06/02
- Re: Support bytesize comparison in sort, Paul Eggert, 2006/06/02
- Re: Support bytesize comparison in sort, Mart Somermaa, 2006/06/07
- Re: Support bytesize comparison in sort, Paul Eggert, 2006/06/07
- Re: Support bytesize comparison in sort, Mart Somermaa, 2006/06/13
- Re: Support bytesize comparison in sort, Paul Eggert, 2006/06/13
- Re: Support bytesize comparison in sort, Mart Somermaa, 2006/06/14