🚀 go-pugleaf

ARaman@massey.ac.nz (Anand Venkata Raman) writes:

>I want to sort a file exclusively on field #2.
>For example,
>A portion of the file looks like
>appl1  3  Submitted
>appl2  4  Submitted
>appl1  3  Started
>appl3  5  Submitted
>appl2  4  Started
>appl1  3  Finished(0)
>appl2  4  Finished(7)
>appl3  5  Started
>appl3  5  Finished(3)

In the bourne shell (sh) :

cat -n file | awk "{print \$3,\$1,\$2,\$4}" | sort | awk "{print \$3,\$1,\$4}"
- line numbers are added
- arguments are rearrange so :
- sort is done on first preference your key, second preference line numbers
- remove the line# are rearrange arguments back

I think I am missing some argument to 'sort' to make it interpret the line
numbers as numbers - not just text.

Stephen Quan,
University of Tasmania.

In article <quan.656735656@sol> quan@sol.surv.utas.oz (Stephen Quan) writes:
>ARaman@massey.ac.nz (Anand Venkata Raman) writes:
>
>>I want to sort a file exclusively on field #2.
>>For example,
>>A portion of the file looks like
>>appl1  3  Submitted
>>appl2  4  Submitted
>>appl1  3  Started
>>appl3  5  Submitted
>>appl2  4  Started
>>appl1  3  Finished(0)
>>appl2  4  Finished(7)
>>appl3  5  Started
>>appl3  5  Finished(3)
>
>cat -n file | awk "{print \$3,\$1,\$2,\$4}" | sort | awk "{print \$3,\$1,\$4}"

Close, but there's no need for two awks (which will mess up the formatting if
white space is important), and you were right about the missing -n:

cudcv (5) > cat -n xx | sort -n +2 -3 +0 -1 | colrm 1 8
appl1  3  Submitted
appl1  3  Started
appl1  3  Finished(0)
appl2  4  Submitted
appl2  4  Started
appl2  4  Finished(7)
appl3  5  Submitted
appl3  5  Started
appl3  5  Finished(3)
cudcv (6) > 

(SystemV-ers will use `cut -c8-' instead of `colrm 1 8'.)

Rob
--
UUCP:   ...!mcsun!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

In article <1990Oct24.161210.15831@warwick.ac.uk> I wrote:
>cudcv (5) > cat -n xx | sort -n +2 -3 +0 -1 | colrm 1 8
>...
>
>(SystemV-ers will use `cut -c8-' instead of `colrm 1 8'.)

But then of course they won't have cat -n ... so they'll have to use 

	pr -tn\ 6 | sort -n +2 -3 +0 -1 | cut -c8-

Rob
--
UUCP:   ...!mcsun!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick             INET:   cudcv@warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England

In <1094@massey.ac.nz> ARaman@massey.ac.nz (Anand Venkata Raman) writes:

>I want to sort a file exclusively on field #2.
 . . . 
>I tried using sort +1 -2, but that doesn't seem to deter sort from looking
>at field #3.

Anand, you cannot deter sort from looking at field three.  Try this:

cat <<EOF | sort +1 -2 +2r
appl1  3  Submitted
appl2  4  Submitted
appl1  3  Started
appl3  5  Submitted
appl2  4  Started
appl1  3  Finished(0)
appl2  4  Finished(7)
appl3  5  Started
appl3  5  Finished(3)
EOF

The +2r sorts the third field in reverse order.

The man page clearly states that you cannot cause sort to ignore a field
or preserve relative line ordering.  From the sort(1) man page
(sys V release 3), under DESCRIPTION:

       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.
                                      ^^^^^^^^^^^^^^^^^^^^^
and (from WARNINGS):

       sort does not guarantee preservation of relative line ordering
       on equal keys.

--
-Rob Lemley, System Consultant, Scanning Software, Intergraph, Huntsville, AL
 ...!uunet!ingr!b15!rob   OR   b15!rob@INGR.COM
 205-730-1546

In article <1757@b15.INGR.COM> rob@b15.INGR.COM (Rob Lemley) writes:

   In <1094@massey.ac.nz> ARaman@massey.ac.nz (Anand Venkata Raman) writes:
   >I want to sort a file exclusively on field #2.
    . . . 
   >I tried using sort +1 -2, but that doesn't seem to deter sort from looking
   >at field #3.

   Anand, you cannot deter sort from looking at field three.  Try this:
   [stuff deleted]
   The man page clearly states that you cannot cause sort to ignore a field
   or preserve relative line ordering.  From the sort(1) man page
   (sys V release 3), under DESCRIPTION:

	  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.
					 ^^^^^^^^^^^^^^^^^^^^^
   and (from WARNINGS):

	  sort does not guarantee preservation of relative line ordering
	  on equal keys.

I'm including a fix that someone posted a while back to make sort preserve
relative line ordering on equal keys.

Enjoy,

-- 
Joe Wells <jbw@bu.edu>
----------------------------------------------------------------------
One of our users needed a version of sort (we're running
4.3bsd) that is stable; ie, lines considered equal are
grouped together but not otherwise rearranged;  For example,
	0 1
	0 0
sorted on the 0th field would not be rearranged.

As distributed, sort's behavior is (from the man page)
"Lines that otherwise compare equal are ordered with all
bytes significant".

We puzzled through sort and came up with a "fix".  One
question about sort though, any idea why ibuf[256] rather
than ibuf[7], since it never seems to merge more than
7 files at a time?

Thanks,

Ron Stanonik
stanonik@nprdc.arpa

Diffs to make sort stable
*** /usr/src/usr.bin/sort.c	Tue Jun  3 16:59:43 1986
--- sort.c	Tue Dec 20 09:00:45 1988
***************
*** 35,40 ****
--- 35,41 ----
  int 	mflg;
  int	cflg;
  int	uflg;
+ int	Sflg;
  char	*outfil;
  int unsafeout;	/*kludge to assure -m -o works*/
  char	tabchar;
***************
*** 206,211 ****
--- 207,216 ----
  					dirtry[0] = *++argv;
  				continue;
  
+ 			case 'S':
+ 				Sflg++;
+ 				continue;
+ 
  			default:
  				field(++*argv,nfields>0);
  				break;
***************
*** 673,678 ****
--- 678,685 ----
  	}
  	if(uflg)
  		return(0);
+ 	if(Sflg)
+ 		return(i < j ? 1 : -1);
  	return(cmpa(i, j));
  }