[Top][All Lists]

[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:
> 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 ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]