[Top][All Lists]

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

Re: Handling time units (ms, us) in sort --human-numeric-sort

From: Pádraig Brady
Subject: Re: Handling time units (ms, us) in sort --human-numeric-sort
Date: Mon, 19 May 2014 23:09:25 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 05/19/2014 07:41 PM, Carl Ponder wrote:
> (This is a feature request, not a bug report, but I couldn't figure out from 
> your website info where else to send it).
> I want to use "sort" to order information in the following format
>    15us
>    9ms
>    10s
> I know that the--human-numeric-sort is able to manage file size units (K, G), 
> but it looks like it is not aware of time units (s, ms, us).
> Is this something you can add?
> I'm using the sort version 8.13 (on Ubuntu 12.04), do you already have this 
> in a more current version?
> I don't see it in your list of rejected requests (!) so I figure there's a 
> chance....

Well this is nothing to do with time, rather supporting fractional SI prefixes:
 'm' for milli, 'u' for micro, 'n' for nano etc.

The nice thing is that we wouldn't have to add any new interface to support 
and the attached trivial patch would work in this and many cases,
because 's' doesn't overlap with any of the suffixes.

  $ printf '%s\n' 10s 15us 9ms 2Gs 8Ms | src/sort -h

However note that the --human support in sort is not general and is
only really suitable for sorting the output from a particular
run of du -h or df -h etc. For example the following non normalized
numbers would not sort correctly:

  $ printf '%s\n' 12345us 10ms  | src/sort -h

Given these suffixes would not be generated by coreutils,
and they're very often not normalized so that the suffix
comparison is invalid independently from the number,
we'd have to employ a more general solution I think.


Attachment: sort-fractional-units.patch
Description: Text Data

reply via email to

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