david@cs.uow.edu.au (David E A Wilson) (04/11/91)
I have run into a bug in the sort(1) command on a Sun4 running SunOS 4.1.1. This occurs both with /usr/bin/sort and /usr/5bin/sort. The problem also appears on a Sequent Symmetry running Dynix 2.0v2 (both ucb sort and att sort) and finally with the sort command compiled using the 4.3-bsd tahoe sources. The bug is as follows. I am trying to sort on the 2nd character of the second field of a colon separated record. If this character compares equal I then sort on the 1st character of the 2nd field. /usr/bin/sort -t: +1.1 -1.2 +1.0 -1.1 <<! abc:Ab:xyz def:zA:pqr ! This results in: Script started on Thu Apr 11 13:16:57 1991 $ /usr/bin/sort -t: +1.1 -1.2 +1.0 -1.1 <<! >abc:Ab:xyz >def:zA:pqr >! abc:Ab:xyz def:zA:pqr $ script done on Thu Apr 11 13:17:11 1991 Which is incorrect. The same input to "sort +0.5 -0.6 +0.4 -0.5" will however work (but is useless if the first field is not fixed length). The problem appears to be in the skip function used to find the start and end of sort keys. Patching it to add one to the end pointer fixes my problem but may introduce other problems. -- David Wilson Dept Comp Sci, Uni of Wollongong david@cs.uow.edu.au
paul@unhtel.unh.edu (Paul S. Sawyer) (04/11/91)
In article <1991Apr11.031926.19901@cs.uow.edu.au> david@cs.uow.edu.au (David E A Wilson) writes: >I have run into a bug in the sort(1) command on a Sun4 running SunOS 4.1.1. >This occurs both with /usr/bin/sort and /usr/5bin/sort. The problem also >appears on a Sequent Symmetry running Dynix 2.0v2 (both ucb sort and att sort) >and finally with the sort command compiled using the 4.3-bsd tahoe sources. > >The bug is as follows. I am trying to sort on the 2nd character of the second >field of a colon separated record. If this character compares equal I then >sort on the 1st character of the 2nd field. > >/usr/bin/sort -t: +1.1 -1.2 +1.0 -1.1 <<! >abc:Ab:xyz >def:zA:pqr >! > >This results in: > ... >abc:Ab:xyz >def:zA:pqr > ... >Which is incorrect. ... > >The problem appears to be in the skip function used to find the start and end >of sort keys. Patching it to add one to the end pointer fixes my problem but >may introduce other problems. That is what you have to do. If you RTFM very carefully, the bug is in the IMPLEMENTATION, such that +m.n does not mean the same as -m.n !! It seems perverse, but you need: /usr/bin/sort -t: +1.1 -1.3 +1.0 -1.2 -- Paul S. Sawyer {uunet,attmail}!unhtel!paul paul@unhtel.unh.edu UNH CIS - - Telecommunications and Network Services VOX: +1 603 862 3262 Durham, New Hampshire 03824-3523 FAX: +1 603 862 2030
gwyn@smoke.brl.mil (Doug Gwyn) (04/13/91)
In article <1991Apr11.031926.19901@cs.uow.edu.au> david@cs.uow.edu.au (David E A Wilson) writes: >I have run into a bug in the sort(1) command on a Sun4 running SunOS 4.1.1. No, it's just a feature. >/usr/5bin/sort -t: +1.1 -1.2 +1.0 -1.1 <<! That should have been sort -t: +1.1 -1.3 +1.0 -1.2 as documented and shown in an example in the SVR2 manual entry SORT(1). This is admittedly a strange design that is hard to use correctly. My guess is that it may have actually been meant to work differently when it was first implemented, but now that the "sort" utility is in wide use the specifications cannot be changed without breaking many applications.