Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.6.2.17 $; site uiucdcs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!ihnp4!inuxc!pur-ee!uiucdcs!liberte
From: liberte@uiucdcs.UUCP
Newsgroups: net.unix
Subject: Re: sort problems
Message-ID: <39300030@uiucdcs.UUCP>
Date: Fri, 25-Jan-85 13:15:00 EST
Article-I.D.: uiucdcs.39300030
Posted: Fri Jan 25 13:15:00 1985
Date-Received: Sun, 27-Jan-85 07:06:45 EST
References: <2040@pegasus.UUCP>
Lines: 29
Nf-ID: #R:pegasus:-204000:uiucdcs:39300030:000:1376
Nf-From: uiucdcs!liberte    Jan 25 12:15:00 1985

On our 4.2bsd, the effect of the -b flag was reversed.  That is, instead
of ignoring leading blanks, it ignores trailing blanks.  

Why?  Possibly because the default action (in the 4.1 distribution) is
screwy.  Instead of specifying field numbers, you specify how many fields to
skip, and then count the leading spaces as part of the next field after
those skipped.

Possibly because the documentation (7th edition) may be misleading.
"The notation +pos1 -pos2 restricts a sort key to a field beginning at pos1
and ending just BEFORE pos2."  Later it says that "...fields are nonempty
nonblank strings separated by blanks."  In any event, it is confusing.
While the b flag on pos1 ignores leading blanks, what is the intended effect
of the b flag on pos2?  The actual effect is to INCLUDE the blanks before
pos2 in the sort key.  So watch out for the global -b.

Partly because of these problems, and partly because I was confused when I
did it, I changed our version of sort to always, really ignore blanks unless
a tab char is specified.  I should have also had the b flag reverse this
effect.  This is what most people want.  But I now think it was a mistake to
change sort at all, even by Berkeley.  There is value in the old way.

Daniel LaLiberte
ihnp4!uiucdcs!liberte
liberte@uiucdcs.Uiuc.ARPA
U of Illinois, Urbana-Champaign, 
Dept of Computer Science
(217) 333-8426