On Sun, Jan 4, 2009 at 5:35 AM, Jim Meyering <[email protected]> wrote:
> However, this assumption might be acceptable (other opinions welcome), > on the condition that the code behind this option diagnoses any violation. Sorry - I missed responding to this part in the previous e-mail. Could you please clarify - what violation is the code supposed to diagnose? There's really no way to do so because my implementation doesn't attempt to understand the input that it's being given: garbage in, garbage out. Since my implementation doesn't know how you've defined your suffixes, so it can't really say - error - you're trying to use a suffix, but the number line has a demarcation at 1024. For instance, maybe to make it nicer to display, you make 0.8 the demarcation of when to switch to using the next suffix e.g. 800 KB/s is actually represented as 0.8MB/s. However, I could look at adding an option (probably not a short option because it's use should also be discouraged since it's a debugging flag) that would allow the user to specify the size of suffixes (i.e. each additional suffix is an additional multiplication by 1024). However, this would make things slightly more complicated because then that number would have to be converted to a string to be compared against both strings in human_compare (to avoid the issues of converting a string to a number). This is a trivial feature - is this what you were thinking of (and once detected, perhaps after the sort print some kind of warning/error that the input was not internally consistent)?. On a side note - additional human-based units (i.e. KB/s) could be trivially supported through the use of sed (something along the lines of `| sed 's/KB\/s/K/' | sort -h | sed 's/K/KB\/s/'`, but more generic). _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
