Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!harvard!panda!genrad!mit-eddie!allegra!jpl
From: jpl@allegra.UUCP (John P. Linderman)
Newsgroups: net.bugs.4bsd,net.unix-wizards
Subject: Re: 4.3BSD sort(1) broken for records with embedded nulls
Message-ID: <6270@allegra.UUCP>
Date: Thu, 21-Aug-86 11:07:59 EDT
Article-I.D.: allegra.6270
Posted: Thu Aug 21 11:07:59 1986
Date-Received: Thu, 21-Aug-86 21:36:17 EDT
References: <491@carina.noao.UUCP>
Reply-To: jpl@allegra.UUCP (John P. Linderman)
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 17
Xref: mnetor net.bugs.4bsd:890 net.unix-wizards:7635

In article <491@carina.noao.UUCP> grandi@noao.UUCP (Steve Grandi) writes:
  >Description:
  >	For 4.3BSD, sort(1) was modified (for efficiency) to use fgets/fputs to
  >read and write data records instead of getc/putc.  This change breaks sort
  >for data records that have embedded nulls; they will generate spurious error 
  >messages "missing newline before EOF" and the data will be totally scrambled.
Sort has never tolerated nulls gracefully.  The way the -u (unique) option
suppresses duplicates is by clobbering the first byte of the record with a
null, and, if you look at line 363 of the 4.3 sort, you'll see that ANY line
that starts with a null will not be written out.  This ``feature'' was
removed in the sort Terry Crowley and I worked over, so I presume it is
also true of recent Sys V sorts.
  >Repeat-By:
  >	Read the code.
I wouldn't wish that on my worst enemy.

John P. Linderman  Department of Marginal Merges and Sordid Sorts  allegra!jpl