Re: sort ignoring human readable suffixes

[Lucas Nussbaum]

On Wed, May 05, 2004 at 11:31:25AM -0700, Paul Eggert <address@hidden> wrote:
> Lucas Nussbaum <address@hidden> writes:
> 
> > Is there a reason why this is not implemented ?
> 
> Lack of time, basically.
> 
> > If not, I'll try to submit a patch adding a -h option, available
> > only with -n.
> 
> Thanks.  Here are some thoughts.
> 
> Beware the decimal-point character: it's locale-dependent.
> 
> Handle both decimal and binary powers of 2, by looking for suffixes
> like "GB" (decimal) versus "G" not immediately followed by "B"
> (binary).
> 
> It's tempting to use strtod but I suspect it won't work in general
> (due to the possibility of misconstruing an 'E' suffix, for exabytes)
> and anyway it'd be faster to avoid floating-point, just as "sort -n"
> does.
> 
> 'h' should be attachable to each sort key, much as 'n' is.
> 
> Finally, will you support -gh as well as -nh?  It's probably not worth
> the hassle but I thought I'd mention the issue.

Hi,

I finally managed to find some time to code this. Here is a patch. The
way it works is quite simple : it first compares according to the suffix
(K,M, etc), then, if the suffixes are equal, it fallbacks to a classic
numeric compare. So 12345K < 1M, but I think it is acceptable if
properly documented (no software will never output 12345K).

Oh and it is just sort -h, not sort -hn.
Example use : du -hs . | sort -h

Tell me what you think of the patch. I'll write the doc and submit
another patch with the doc if you accept it.
-- 
| 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 |

coreutils-5.2.1+sort-h.diff
Description: Text document