Re: Support bytesize comparison in sort

[Mart Somermaa]

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.