Vitali Lovich wrote: > On Tue, Jan 6, 2009 at 12:26 PM, Pádraig Brady <p...@draigbrady.com> wrote: >> Vitali Lovich wrote: >>> On Tue, Jan 6, 2009 at 10:19 AM, Pádraig Brady <p...@draigbrady.com> wrote: >>>> I like the idea. >>>> >>>> So it doesn't support sorting these correctly for example: >>>> >>>> 999MB >>>> 998MiB >>>> 1GiB >>>> 1030MiB >>>> >>>> I.E. a mixture of ^2 and ^10 are not supported, >>>> nor overlapping number ranges. >> I'm not complaining about the above. Just clarifying. >> >>>> + /* FIXME: maybe add option to check for longer suffixes (i.e. gigabyte) >>>> */ >>>> >>>> You should allow at least G, GiB and GB formats. >>>> Probably should print error if more than one of those >>>> formats used, since that's not supported. > Perhaps - but for sort, at least from my thinking of how I would > implement this, the additional logic (at least to behave correctly on > all inputs) would be somewhat complicated.
I thought it would be easy just to ignore a trailing i?B? > Can you please explain why > you believe this belongs in sort because I think it's a common enough format and getting more common since it's an IEC defined standard. > and wouldn't be better served by > pre-processing the text before sort & post-processing it after as > necessary? that's a little awkward and inefficient. > Supporting all the various ways the human_readable can be output is > just not practical or even useful just ignore an optional trailing iB is all I'm suggesting. If it's difficult or inefficient then don't worry about it. >> Alternatively you could allow any string starting with [KMGT..] >> to allow things like KB/s KiBuckets, but then it would be >> tricky to flag mixtures of KiB and KiBuckets as an error for example. > That's definitely not an acceptable solution because the behavior > would be incorrect if you had something like 2Klingongs. lol good example. Yes you're right. >>>> Yep if you're not supporting overlapping number ranges then >>>> you can skip the number comparison totally if the suffixes don't match. > Debatable. You'd still have to scan the string to find the end of the > number to find the suffix. And if you get a miss (i.e. same > suffix-level), then you'll have to scan the strings again, performing > the comparison. don't worry about this for the moment. thanks, Pádraig. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
