In message <[log in to unmask]>, [log in to unmask] writing 
at 19:25:45 in his/her local time opines:-
>Roy,
>
>There seems to be a difference to the sort command depending on if it 
>UNIX or  Linix.
>
>I am using HP9000 UNIX.
>
>Olav.

Hi Olav

That was supposed to be a UNIX, not a Linux, but I suppose all the 
UNIXes are different as well.

I certainly remember that there was someone who issued a UNIX command on 
a production HPUX server here, and brought the thing to a shuddering 
halt - I think because they managed to rename the server on-the-fly or 
something equally unexpected.

Hmmm. So no -s, and -z means something completely different. I love 
standardisation!

Anyway, here's something from the HP-UX man pages for sort that may be 
applicable:-
=====================================================
When there are multiple sort keys, later keys are compared only after 
all earlier keys compare equal.  Lines that otherwise compare equal are 
ordered with all bytes significant.  If all the specified keys compare 
equal, the entire record is used as the final key.
=====================================================
Is it that the final sentence applies, even though you only specified 
one key, and you are getting an implied 'final key' of the whole record?

In which case, it does not look as if you can do a stable sort in HPUX, 
short of appending a record number to each entry, using that as a second 
key, and stripping it off again afterwards.

But maybe someone with a better idea of what they are talking about can 
chip in here?

Roy

>Roy Brown wrote:
>
>> In message <[log in to unmask]>, Olav Kappert 
>><[log in to unmask]> writing at 16:32:19 in his/her local time 
>>opines:-
>>
>>> I would like to know the background for how the Unix sort works with 
>>>keys.
>>>
>>> The cmd is   ---  sort -t \& -o outfile -k 1.1,1.12 filea fileb  ---
>>>
>>> where filea and fileb are the input files and they are both 80 bytes 
>>>in length or in the unix world as byte stream.
>>>
>>> Since there is no "&" character in the file, it will treat the whole 
>>>record as one field.
>>>
>>> When looking at the data, it seems that the key was actually 
>>>extended  for the length of the record or data while it should only 
>>>be looking  at the 12 bytes in the key.
>>>
>>> This behavour is counter to the chronical order of the information 
>>>placed in the file.
>>>
>>> Does anyone have a solution as to how to sort/merge the files and 
>>>retain the chronical order otherwise ?
>>>
>>> ~~~~~
>>> Just to make it interesting I also get the following message:
>>>
>>>   sort: Warning: A newline character was added to the end of the input.
>>>
>>> for each record sorted/merged.
>>>
>>> Why and how do you get rid of this message other than redirecting it 
>>>to $null.
>>>
>>> Olav.
>>
>>
>> Forgot to quote the man page reference.:-
>>
>> http://unixhelp.ed.ac.uk/CGI/man-cgi?sort
>>
>> Note also the -z option that may address your newline issue
>> and the comment about locale LC_ALL=C may also be germane.
>>
>> Roy
>>

-- 
Roy Brown        'Have nothing in your houses that you do not know to be
Kelmscott Ltd     useful, or believe to be beautiful'  William Morris

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *