GNU bug report logs - #40226
sort: expected sort order when -c in use

Previous Next

Full log

View this message in rfc822 format

From: Richard Ipsum <richardipsum <at> vx21.xyz>
To: Eric Blake <eblake <at> redhat.com>
Cc: 40226 <at> debbugs.gnu.org
Subject: bug#40226: sort: expected sort order when -c in use
Date: Wed, 25 Mar 2020 21:02:32 +0100

On Wed, Mar 25, 2020 at 01:17:19PM -0500, Eric Blake wrote:
> On 3/25/20 12:37 PM, Richard Ipsum wrote:
[snip]
> 
> See the difference?  In the first case, sort is doing its default
> case-insensitive comparison of the entire line (because you passed -f but
> not -k), AND a stability comparison of the byte values of the entire line
> (as shown by the two ____ lines per input).  But in the second case, when
> you add -s, the stability comparison is omitted.  The two lines are indeed
> different when the stability comparison is performed, explaining why -c
> choked when -s is absent.  Or put another way, -f affects only -k, including
> the implied -k1 when you don't specify anything, and not -s.  So now that we
> know that, let's return to your example:

I'm trying to understand this relative to POSIX, which makes no mention
of stability as far as I can see (and there is no -s in POSIX). POSIX
says that -f should override the default ordering rules. I don't
understand why the last-resort comparison is required when -c is in use,
since we're not sorting with -c, just checking if the input is already sorted?

Put another way should -c imply -s ?

Thanks,
Richard

Previous Next

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