Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Sort bug causes data loss
Keywords: bug, sort
Message-ID: <4078@auspex.auspex.com>
Date: 19 Sep 90 17:21:38 GMT
References: <2675@crdos1.crd.ge.COM> <13761@ulysses.att.com>
Organization: Auspex Systems, Santa Clara
Lines: 32

>The next clue is from the System V manual page again:
>
>     -n	  An initial numeric string, consisting	of optional
>	  blanks, optional minus sign, and zero	or more	digits
>	  with optional	decimal	point, is sorted by arithmetic
>	  value.  The -n option	implies	the -b option (see
>	  below).  Note	that the -b option is only effective when
>	  restricted sort key specifications are in effect.

And a further clue comes from the SunOS 4.0.3 manual page:

  SYSTEM V DESCRIPTION
       When no fields are specified in the command line, the System
       V version of sort treats leading blanks as significant, even
       with the -n (numeric collating sequence) option; the lines:
            123
              23

       are collated as:
              23
            123

I.e., this is one of the places where the SunOS "/usr/bin/sort" and
"/usr/5bin/sort" differ in their behavior.

(They're both built from the same source code, BTW, which is basically
the S5R2 "sort", that being significantly faster than the V7-vintage
sort that comes with 4.3BSD; see J. P. Linderman's paper in the
October 1984 AT&T Bell Laboratories Technical Journal, October 1984,
Vol. 63 No. 8 Part 2 - the second special UNIX issue - which discusses
work on sorting that, I think, got into the S5 sort in S5R2.  There's an
"#ifdef S5EMUL" that governs which of the behaviors is selected.)