Xref: utzoo comp.bugs.sys5:1501 comp.bugs.4bsd:1787
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!unhd.unh.edu!unhtel!paul
From: paul@unhtel.unh.edu (Paul S. Sawyer)
Newsgroups: comp.bugs.sys5,comp.bugs.4bsd
Subject: Re: Bug in sort(1) when using +m.n -o.p and -tc
Keywords: sort bug
Message-ID: <1991Apr11.154818.18576@unhtel.unh.edu>
Date: 11 Apr 91 15:48:18 GMT
References: <1991Apr11.031926.19901@cs.uow.edu.au>
Organization: UNH Telecommunications and Network Services
Lines: 36

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