Re: bin/51726: sort -n ignored if given after -k

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/51726; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/51726: sort -n ignored if given after -k
Date: Sun, 18 Dec 2016 15:23:38 +0700

     Date:        Sun, 18 Dec 2016 02:05:01 +0000 (UTC)
     From:        David Holland <dholland-bugs%netbsd.org@localhost>
     Message-ID:  <20161218020501.468347A302%mollari.NetBSD.org@localhost>
 
   |  If you're using -k you're supposed to put the key flags in the -k
   |  argument, that is, sort -k 3nr.
 
 Not quite, using global options is still fine, they're just not
 supposed to apply to a key specified if that key has any sort selections
 of its own.
 
 Our sort doesn't do that, it merges global options and key specific
 options, in a kind of weird way --- but the behaviour described (while
 perhaps not strictly correct) is I think what is intended.
 
 That is, when sorting a key field, you get whatever sort options are
 specified for that key, merged with whatever global options had already
 been given - later global options are supposed to affect the next key
 (or the backup default sort if the keys are equal).   That is, that's how
 the NetBSD sort is written.
 
   |  Technically I think if you write -k 3 -n -r and it doesn't honor the
   |  -n it's doing what you asked.
 
 According to our sort's design, yes, though I don't think that is posix.
 
   | And I think if you write -k 3 -n -r and
   | it *does* sort in reverse order, then *that*'s a bug. sigh.
 
 Yes, probably.
 
   |  sort's argument handling is a trainwreck.
 
 That mild?
 
   |  And thus the code in sort that deals with it is horrifying.
 
 Yes.   We could probably simplify it a lot if we made it posix
 conformat (where any key specific ordering options disable all
 the globals for that key) but it has been as it is for a long time
 now (mayve even, modulo the k stuff) has been like it since 6th or
 7th edition unix.   So changing it might break a lot - who knows?
 
   | I know why POSIX wanted to get rid of "sort +3", but it *worked*...
 
 That change is actually a separate isue, and other than that people tend
 not to really understand what the key selection stuff does, that works
 as well.   And the +3 variant is still there as well...
 
 kre