Bug in sort(1) when using +m.n -o.p and -tc

Paul S. Sawyer paul at unhtel.unh.edu
Fri Apr 12 01:48:18 AEST 1991


In article <1991Apr11.031926.19901 at cs.uow.edu.au> david at 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 at unhtel.unh.edu
UNH CIS - - Telecommunications and Network Services      VOX: +1 603 862 3262
Durham, New Hampshire  03824-3523                        FAX: +1 603 862 2030



More information about the Comp.bugs.sys5 mailing list