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

[Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>]

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

From: Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>
To: NetBSD GNATS <gnats-bugs%netbsd.org@localhost>
Cc: abhinav%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
	abs%absd.org@localhost
Subject: Re: bin/51726: sort -n ignored if given after -k
Date: Sun, 18 Dec 2016 21:54:42 +0530

 On Sun, Dec 18, 2016 at 1:55 PM, Robert Elz <kre%munnari.oz.au@localhost> wrote:
 > 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 have been going over the sort(1) man page from posix, and at one
 place (in the APPLICATION USAGE section) it says the following about
 the use of ordering options after -k:
 
 "The wording in the OPTIONS section clarifies that the -b, -d, -f, -i,
 -n, and -r options have to come before the first sort key specified if
 they are intended to apply to all specified keys. The way it is
 described in this volume of POSIX.1-2008 matches historical practice,
 not historical documentation. The results are unspecified if these
 options are specified after a -k option."
 
 So, I guess using `sort -k3 -n -r` is undefined behavior?. That said,
 the example mentioned in the PR (sort -k 2 -n -r) does work with GNU
 sort(1). I had a patch ready yesterday, so just posting it here :)
 
 This patch lets sort(1) associate -b, -d, -f, -i, -n, -r options to
 specific fields if specified after -k.  All ATF tests for sort(1) are
 passing except for a couple of cases in kflag_alpha, but they look
 ambiguous to me and one of the similar tests is commented out as
 broken. If we want to accept this behavior in our sort(1) and the
 patch looks in the right direction, I will try to dig in and get those
 test cases passing  :)
 
 http://www.netbsd.org/~abhinav/sort.c.diff
 
 -
 Abhinav