grandi@noao.UUCP (Steve Grandi) (08/20/86)
Subject: sort will no longer work on records with embedded nulls
Index: usr.bin/sort.c 4.3BSD
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.
Repeat-By:
Read the code.
Fix:
1) Reinstall the slow 4.2BSD version.
2) Don't use sort(1) as a quick hack when you really should use qsort(3)
--
Steve Grandi, National Optical Astronomy Observatories, Tucson, AZ, 602-325-9228
{arizona,decvax,hao,ihnp4,seismo}!noao!grandi grandi%draco@Hamlet.Caltech.Edujpl@allegra.UUCP (John P. Linderman) (08/21/86)
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