Paul Eggert wrote: > Mart Somermaa <[EMAIL PROTECTED]> 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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
