Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!allegra!jpl
From: jpl@allegra.UUCP (John P. Linderman)
Newsgroups: net.bugs,net.bugs.4bsd,net.bugs.usg
Subject: Re: Sort feature ?
Message-ID: <6256@allegra.UUCP>
Date: Fri, 15-Aug-86 11:11:34 EDT
Article-I.D.: allegra.6256
Posted: Fri Aug 15 11:11:34 1986
Date-Received: Sun, 17-Aug-86 06:12:12 EDT
References: <247@petrus.UUCP> <5922@sun.uucp>
Reply-To: jpl@allegra.UUCP (John P. Linderman)
Distribution: net
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 72
Xref: mnetor net.bugs:321 net.bugs.4bsd:880 net.bugs.usg:350

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