Michael Speer wrote: > 2009/4/25 Pádraig Brady <[email protected]>: >> I've further modified your latest in the attached. >> I refactored the suffix finding a bit and also added >> support for --sort=human-numeric. > > I refactored it again to handle some potential problems with how > separators and decimals points were handled.
find_unit_order() is a better refactoring, thanks. > It will still let you > write something silly like "1,3,4.5.6", but I've stopped scanning on > "4..4" or "3,,2" or even "5.M". I'm not sure if that last one is used > meaningfully anywhere. That's an improvement. I'll have to do some benchmarking to see if these extra checks have any significant effect. > I did this partly to avoid breaking locales > where space is the separator. Supporting spaces in numbers is problematic anyway due to the way fields are handled. Good to have the space as thousands separator handled anyway. > I poked around a bit to see if any locales used space. > Apparently, the Hungarian locale does. I stopped looking there. Doesn't have spaces here at least: LANG=hu_HU.utf8 printf "%'d\n" 1234 >> I'm wondering whether "numeric" is superfluous? >> I.E. are --sort=human and --human-sort sufficient. >> > > I started with just human, but thought it better to add the numeric > since sort is by default for strings, and both current switches that > enable numeric sorts have it in their name. I would not fight a > reversion on this if no one thought it would look confusing or too > inconsistent to end users. Well I was worried about it being too verbose, but it is more consistent with other numeric options, so we'll leave it as is I think. OK, I'll do up docs and tests tomorrow for this. If you would prefer to do that please shout now. cheers, Pádraig. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
