Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!motcsd!hpda!hpcuhc!hpsemc!gph
From: gph@hpsemc.HP.COM (Paul Houtz)
Newsgroups: comp.unix.questions
Subject: Re: sort question
Message-ID: <810054@hpsemc.HP.COM>
Date: 16 May 89 17:04:49 GMT
References: <199448@hrc.UUCP>
Organization: HP Technology Access Center, Cupertino, CA
Lines: 30

chris@mimsy.UUCP (Chris Torek) writes:

>In article <810050@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes:
>>Right.  There is no way to do a true column sort using this utility as you
>>can on IBM or MPE systems and here is why:   Sort requires a FIELD DELIMITER
>>character.   That means that there is SOME character that will never be 
>>sorted.
>
>But (as you yourself point out) you can set the field delimiter to
>newline, effectively making it vanish, then use the 0.n format to
>specify column n.

   Wouldn't it be nice if the whole world spoke Unix.  It would make any
minor user Unfriendliness seem like such a minor issue.  Oh well.  Unfortunately
there will probably always be systems out there that need to talk to non-
unix systems.    
  
   The problem with having to set the field delimiter is that you have to
decide what to set it TO.  Now, if you are reading from a file that has 
binary data in it, then it is possible that a newline character could appear
in the binary data.  This seems to me like it might be a problem.   Sort
would think it found the end of line.

   I can write a sort program that will do this column sorting for me, but
what a pain.  It's too bad there isn't one for unix, like there is for 
all the other major operating systems.

   (On the other hand, I'll be that some third party out there has already
written a true column sort for unix.  I just haven't found it yet.  Any
takers?)