"Vitali Lovich" <vlov...@gmail.com> wrote: ... >> 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.
I agree that ignoring the valid suffixes is worthwhile. Remember that df and du support the --block-size option, (or equivalently, via one of the BLOCK_SIZE envvars) so people may be running "du --block-size=MiB -s /tmp", which produces output like this: 27MiB /tmp As such, I'd like GNU sort to handle input like that. You could argue that the numbers might have "." or "," thousands separators: $ LC_ALL=en_US du --block-size=\'1 -s /tmp 27,905,024 /tmp but I don't think it's worthwhile to parse those. >> If it's difficult or inefficient then don't worry about it. > Right, but you have to deal with terminating characters and whatnot. > I mean it's not super difficult obviously. I'm just wondering why > that logic even belongs in sort. The rule of thumb is - the less code > you write, the fewer bugs you'll have. Sure, but usability counts, too. If we stuck mindlessly to the less-code-is-better mantra, coreutils would look very different than it does now. Finding the right balance isn't easy. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
