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: Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>
Cc: NetBSD GNATS <gnats-bugs%netbsd.org@localhost>, 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 14:59:37 +0700

     Date:        Tue, 27 Dec 2016 10:30:49 +0530
     From:        Abhinav Upadhyay <er.abhinav.upadhyay%gmail.com@localhost>
     Message-ID:  <CAHwRYJnPTdDbQi1FOROG_MbLDrUHGpD7BOfPRuLnhydUAGOqFw%mail.gmail.com@localhost>
 
   | 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
 
 The first 2 chunks of that appear to change the way that global opts
 after a -k are linked in ... before the change
 
 	sort -d -k1,2f -i k2,3n
 
 would (incorrectly according to posix) sort on the first key with the d & f
 flags (posix would expect only f) and then the 2nd key with d i & n flags
 (and then if needed, the whole record with d and i flags).
 
 After your proposed change, as I read it, the effect would be to sort
 on the first key with d f and i flags, and then the second key with d and n
 flags (and then the whole record with just d).
 
 Since the meaning of global opts after a -k is explicitly undefined, making
 that change is something that could be done, but I am not sure that there
 is really any overall merit in it.   What we have now isn'tgreat, but at
 least can be explained, global options apply to all following -k's, and
 so has some potential use.
 
 After the change, glbal options after a -k are essentially just attached
 to the preceding -k, right, so
 
 	sork -k1,2 -n
 
 is exactly the same as
 
 	sort -1,2n
 
 I am not sure there is any real point to that.
 
 The third change in the diff looks to be just churn, whcih changes nothing,
 and shouldn't really be there at all.
 
 kre
 
 ps: neither you, nor I above, made any reference to the r flag, which is
 currently just different, and really should not be (but its current impl
 is scattered all over.)