guy@sun.UUCP (08/07/86)
> The reason is that sort considers the delimiter as a field terminator > and not as a field separator. Does anyone have a fix for this > feature (bug)? This behavior persists in the S5R2 "sort", which seems to be derived from Linderman's (answering your second question). The real question is "Does anybody know whether: this is considered a feature, and thus should not be fixed; this is just a bug that nobody in a position to do anything about it has encountered or had pointed out to them; or this is just incredibly hard to fix without breaking something else?" It certainly violates the Principle of Least Surprise, and has probably caught enough people unawares; is there anything out there that *depends* on this gross behavior? -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
jpl@allegra.UUCP (John P. Linderman) (08/15/86)
In article <5922@sun.uucp> guy@sun.UUCP quotes and comments: >> ... sort considers the delimiter as a field terminator and not >> as a field separator. Does anyone have a fix for this feature (bug)? > >This behavior persists in the S5R2 "sort", which seems to be derived from >Linderman's (answering your second question). The real question is "Does >anybody know whether: > > this is considered a feature, and thus should not be fixed; > > this is just a bug that nobody in a position to do anything > about it has encountered or had pointed out to them; > >or > > this is just incredibly hard to fix without breaking something > else?" > >It certainly violates the Principle of Least Surprise, and has probably >caught enough people unawares; is there anything out there that *depends* on >this gross behavior? I responded to Derek Burns, the original poster, by mail, but confusion seems to be spreading, so it's time to go public. Items are covered in decreasing order of relevance... quit when you get bored. If I try sort<<! a b a a ! I do NOT expect to have the order of the lines reversed, even though my field separators are blank and tab by default. If I supply an explicit field separator, but don't do anything with fields, like Derek's sort -t/ <<! abc/ abc,/ abc / ! I would expect (and I get) the same behavior... the lines are sorted as ascii strings. The delimiter is NOT being treated as a field terminator. Indeed, there aren't any fields. If I specify that I want to sort on the first field, by saying "sort -t/ +0 -1 <<!", I will get the behavior that Derek and Guy presumably wanted (but didn't ask for). Lest anybody think that I believe that sort is surprise-free, try sort +1 -2<<! a b a a ! and note that the order of the lines is STILL not reversed. Try +1b to get the effect you probably wanted. That sure surprised me the first time I tried it. I asked for (and got) some clarification in the documentation. The latest SVID I saw says something like ``All blanks in a sequence of blanks are considered to be part of the next field; for example, all blanks at the beginning of the line are considered to be part of the first field.'' And there is no sure-fire way of saying "sort on ALL /-delimited fields", which may well be what people expect "sort -t/" to do. Fielding is not a strong point of sort, either in clarity or efficiency. The term ``Linderman's sort'' is appropriate only in the sense that I wrote about it in a BSTJ article. The changes discussed there were only evolutions of the original /bin/sort (author or authors unknown to me), the changes discussed were done by Terry Crowley as well as me, and the sort that goes out with System V has had further improvements at the hands of the systems developers at ATT-IS. I'm pleased that Terry and I made sort a little safer, but it's not a piece of software I am eager to be remembered by. John P. Linderman Department of Utter Disorder allegra!jpl