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, 
	David Brownlee <abs%absd.org@localhost>
Subject: Re: bin/51726: sort -n ignored if given after -k
Date: Tue, 27 Dec 2016 10:30:49 +0530

 On Tue, Dec 20, 2016 at 9:30 PM, Abhinav Upadhyay
 <er.abhinav.upadhyay%gmail.com@localhost> wrote:
 > On Sun, Dec 18, 2016 at 9:54 PM, Abhinav Upadhyay
 > <er.abhinav.upadhyay%gmail.com@localhost> wrote:
 >> 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
 >
 
 I have a new patch which fixes this issue without breaking any tests,
 please have a look:
 
 http://netbsd.org/~abhinav/sort.c.diff_v2
 
 -
 Abhinav