Andy Jewell <[EMAIL PROTECTED]> wrote: > In the test suite for sort (coreutils 6.9), there are two tests that > seem to be testing for incorrect behavior.
Do you know of a version of sort that fails those two tests? > I'm hoping someone will help me understand why the behavior in the > test is correct. When I wrote about this over 11 years ago, POSIX did not specify sort's behavior with such options. But all implementations worked the way GNU sort now works. > Here are the commands, and the expected output. (The tests are 10f and > 10g). > > > sort -t : -k 1.3,1.3 > :ba > :ab > > > sort -k 1.4,1.4 > b ba > a ab > > > In both of these cases it seems that the explicit -k matches an empty > string, which would compare equal, so it would fall back to the last > resort memcmp of the whole line, which would produce the opposite > ordering from above. > > So what am I missing? It is counter-intuitive, indeed. The vague ChangeLog reference in the comment there, gives a clue. Here's the change it's talking about: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3c467c0d223 The examples above select the "location" of the first field, which happens to be empty, then the 3rd/4th following byte respectively. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
