Subject: Re: bug#22109: Sort gives incorrect order when changing delimiters

From: Ed Brambley <[email-masked]>
Date: Tue, 8 Dec 2015 09:50:34 +0000

Dear All,

Thanks Assaf and Eric for the explanation.  It's very well hidden in the
man page.  I know it would break backward compatability (so don't do it)
and, as Eric pointed out to me, would break POSIX compatability, but I
would think most people's expectation would be that -k2 would be shorthand
for -k2,2 rather than -k2,end.

Updating the documentation would really help.  Your proposals so far seem
good, but they are really missing the point as far as I'm concerned, which
is that *field separators are including in the comparison*,  So I think
Paul's update is a bit misleading, as it says "Sort compares each pair of
fields, in the order specified on the command line, according to the
associated ordering options, until a difference is found or no fields are
left", but doesn't mention that it also uses the field separators when
comparing fields.

If I'd seen the documentation suggesting using --debug, I would have used
it, but still reported a bug as --debug would have just confirmed that sort
was doing what I thought it was doing, which I thought was wrong.

So parhaps we could say somewhere in the documentation something like:

> KEYDEF is F[.C][OPTS][,F[.C][OPTS]] for start and stop position, where F
is a
> field number and C a character position in the field; both default to 1,
and
> the stop position defaults to the line's end.  Note that any field
separators between
> the start and stop positions are also included in the comparison.

And also possibly something like:

> ... A line's trailing newline is not part of the line for comparison
purposes, but field
> separators are included in the comparison...

Thanks again,
Ed

Ps: Sorry for emailing you directly, Eric.  My fault for not replying all.