linda@cc.brunel.ac.uk (Linda Birmingham) (11/14/89)
Has anyone noticed a diference in operation in the 'sort' command from OSx4.0 to 4.4 ? We had a user application that used to work with 'sort' in 4.0 and doesn't in 4.4. When we restrict sorting to a particular field it still insists on sorting on the first field afterwards. Try sort +1 -1.4 try where try is: wwww 0020 ctre ge zzzz 0080 btre ge vvvv 0110 gtre ge yyyy 0090 dtre ge tttt 0020 atre ge ssss 0040 ftre ge and notice that the tttt line is placed before the wwww line. Any comments anyone ?? Linda. -- Brunel University, Uxbridge, Middlesex, England. janet: linda@uk.ac.brunel.cc | :-) uucp:...ukc!cc.brunel!linda |
kenj@yarra.oz.au (Ken McDonell) (11/22/89)
In article <1155@Terra.cc.brunel.ac.uk> linda@cc.brunel.ac.uk (Linda Birmingham) writes: > Has anyone noticed a diference in operation in the 'sort' command > from OSx4.0 to 4.4 ? > > We had a user application that used to work with 'sort' in 4.0 > and doesn't in 4.4. I cannot explain this, although the example given seems to behave as expected. > When we restrict sorting to a particular field it still insists on sorting > on the first field afterwards. > > Try sort +1 -1.4 try > > where try is: > wwww 0020 ctre ge > zzzz 0080 btre ge > vvvv 0110 gtre ge > yyyy 0090 dtre ge > tttt 0020 atre ge > ssss 0040 ftre ge > > and notice that the tttt line is placed before the wwww line. > > Any comments anyone ?? This will sort on the first four characters of the second field. sort(1) uses base zero numbering for fields and field-offsets. to sort of the first field, you need ssss 0040 ftre ge ^ ^ | | 0 0.3 (but want to finish just before 0.4, so -0.4 or -1) i.e. sort +0 -0.4 (or sort +0 -1) which both produce ssss 0040 ftre ge tttt 0020 atre ge vvvv 0110 gtre ge wwww 0020 ctre ge yyyy 0090 dtre ge zzzz 0080 btre ge the original sort +1 -1.4 produces tttt 0020 atre ge wwww 0020 ctre ge ssss 0040 ftre ge zzzz 0080 btre ge yyyy 0090 dtre ge vvvv 0110 gtre ge note the second field is sorted into lexicographic order. while I am in tutor mode, be careful of numeric fields as well. if the leading zeroes are stripped from the second field, then sort +1 -2 produces vvvv 110 gtre ge tttt 20 atre ge wwww 20 ctre ge ssss 40 ftre ge zzzz 80 btre ge yyyy 90 dtre ge to sort on the numeric value of the second field requires sort +1n -2 tttt 20 atre ge wwww 20 ctre ge ssss 40 ftre ge zzzz 80 btre ge yyyy 90 dtre ge vvvv 110 gtre ge
tim@brspyr1.BRS.Com (Tim Northrup) (11/30/89)
linda@cc.brunel.ac.uk (Linda Birmingham) writes: >When we restrict sorting to a particular field it still insists on sorting >on the first field afterwards. >Try sort +1 -1.4 try >where try is: >wwww 0020 ctre ge >tttt 0020 atre ge >and notice that the tttt line is placed before the wwww line. >Linda. This action seems correct to me, at least on my interpretation of the man page for sort(1). From the System V User's Manual: "Lines that otherwise compare equal are ordered with all bytes significant." This is after the section discussing sort keys. In my own opinion, since you only requested a sort on the 2nd word of each line, you should consider the order of the remainder of the fields as undefined! I would expect the sort algorithm to only sort on the fields I requested it to, and if 2 records are equal for those tested fields then they would be placed on the output in whichever order makes the sort program happy. Just my 2 cents worth ... -- Tim -- Tim Northrup +------------------------------------------+ +---------------------------------+ GEnie: T.Northrup | UUCP: uunet!crdgw1!brspyr1!tim | Air Warrior: "Duke" | ARPA: tim@brspyr1.BRS.Com +------------------------------------------+