Re: Need help understanding sort tests

[Jim Meyering]

Andy Jewell <address@hidden> 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.