GNU bug report logs - #22109
Sort gives incorrect order when changing delimiters

Previous Next

Package: coreutils;

Reported by: Ed Brambley <edbrambley <at> gmail.com>

Date: Mon, 7 Dec 2015 16:17:03 UTC

Severity: normal

Tags: notabug

Done: Eric Blake <eblake <at> redhat.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ed Brambley <edbrambley <at> gmail.com>
To: 22109 <at> debbugs.gnu.org
Subject: bug#22109: Sort gives incorrect order when changing delimiters
Date: Tue, 8 Dec 2015 09:50:34 +0000
[Message part 1 (text/plain, inline)]
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.
[Message part 2 (text/html, inline)]

This bug report was last modified 9 years and 166 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.