bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sort ignoring human readable suffixes


From: Lucas Nussbaum
Subject: Re: sort ignoring human readable suffixes
Date: Mon, 6 Sep 2004 11:43:48 +0200
User-agent: Mutt/1.5.6+20040818i

On Sun, Sep 05, 2004 at 04:49:38PM -0700, Paul Eggert <address@hidden> wrote:
> Lucas Nussbaum <address@hidden> writes:
> 
> > So 12345K < 1M, but I think it is acceptable if
> > properly documented (no software will never output 12345K).
> 
> Unfortunately some software does output "12345K".  For example:
> 
> $ echo '' | dd bs=1 seek=12641279 of=big
> 1+0 records in
> 1+0 records out
> $ ls -l --block=K big
> -rw-r--r--  1 eggert eggert 12345K 2004-09-05 16:42 big
> 
> I don't see an easy, efficient fix for this.  If we want to be able to
> handle binary multipliers like the "K" above, and we want to avoid
> errors, we need to have multiword arithmetic.
> 
> > Oh and it is just sort -h, not sort -hn.
> 
> It's OK for -h to imply -n, but it'd be nice if it could also be
> combined with -g.  Come to think of it, if -h implied -g instead, you
> might have a simpler implementation (albeit one with rounding errors
> and slower performance).

This would break with exabytes. My need for this is only to be able to
sort output of commands like du -h. I think that's what most people
would use it for.

Don't you think we should document this properly, with what doesn't work
too, and that it would be enough for most people's need ?
-- 
| Lucas Nussbaum
| address@hidden    address@hidden    GPG: 1024D/023B3F4F |
| jabber: address@hidden   http://www.lucas-nussbaum.net |
| fingerprint: 075D 010B 80C3 AC68 BD4F B328 DA19 6237 023B 3F4F |




reply via email to

[Prev in Thread] Current Thread [Next in Thread]