[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: |
Wed, 07 Jun 2006 12:25:34 +0300 |
User-agent: |
Thunderbird 1.5.0.2 (X11/20060522) |
Paul Eggert wrote:
> Mart Somermaa <address@hidden> writes:
>
>
>> But I really don't see what's wrong with that assumption. It holds for
>> other coreutils and that's what matters most. A clearly documented
>> limitation is not a bug, but a feature :) .
>>
>
> Thanks for explaining it: I now understand why the proposed code
> thinks "1023G" is smaller than "1.0T".
>
> I still see a problem, though, in that if we later decide that we want
> to handle arbitrary numbers, not just "properly scaled" numbers, we'll
> need to have two flags, one that assumes powers of 1000, the other
> powers of 1024. I wouldn't be surprised if this need arose sooner
> rather than later.
>
> I still suspect that we need a more-general mechanism for specifying
> lots of different sort flags. The flag you're proposing is quite
> specific: it is designed for numbers output by coreutils and a few
> similar GNU programs. While it's useful behavior, I'm not yet
> convinced it's worth chewing up one (and quite possibly two) option
> letters for. If we could support it with a long option now, and see
> how popular it is in practice, we might later add it as a short
> option.
>
Why not use an upper-case letter? We have plenty of those left. Let me
know and I'll update the code with '-H'. However, as already discussed,
we need a single option letter -- think of `df -h | sort -k 3h` etc.
I'm afraid I don't agree in regard of specificness. On the contrary, if
suffixes are used at all, the output is *generally* properly "scaled".
Improper scaling is a specific, obscure corner case. Again, can you
think of a single contradicting example?
The only problem I see is sorting mixed input.