Re: Support bytesize comparison in sort

[Paul Eggert]

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.