[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#40226: sort: expected sort order when -c in use
From: |
Richard Ipsum |
Subject: |
bug#40226: sort: expected sort order when -c in use |
Date: |
Wed, 25 Mar 2020 21:02:32 +0100 |
User-agent: |
Mutt/1.12.2 (2019-09-21) |
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