Sort feature ?

2 views
Skip to first unread message

derrick burns

unread,
Aug 4, 1986, 1:14:41 PM8/4/86
to
There appears to be a bug with sort in its treatment of field
delimiters. For example:

sort -t/ <<!
abc/
abc,/
abc /
!

Produces:

abc /
abc,/
abc/

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)? Also, does anyone have a copy of John Linderman's
sort which allows arbitrary length lines (up to the available memory)?

g...@sun.uucp

unread,
Aug 7, 1986, 3:49:58 AM8/7/86
to
> 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
g...@sun.com (or g...@sun.arpa)

John P. Linderman

unread,
Aug 15, 1986, 11:11:34 AM8/15/86
to
In article <59...@sun.uucp> g...@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

Reply all
Reply to author
Forward
0 new messages