Bug#373704: sort -k does not count fields the same as gnu sort

[Rob Landley]

Ok, I looked closer at the test case and added it to the test suite.

On Thursday 15 June 2006 4:27 am, Bastian Blank wrote:
> --- sort.c	(revision 1213)
> +++ sort.c	(local)
> @@ -72,17 +72,18 @@
>  		else {
>  			end=0;
>  			for(i=1;i<key->range[2*j]+j;i++) {
> -				/* Skip leading blanks or first separator */
> +				/* Skip leading blanks */
>  				if(str[end]) {
> -					if(key_separator) {
> -						if(str[end]==key_separator) end++;
> -					} else if(isspace(str[end]))
> +					if(isspace(str[end]))
>  						while(isspace(str[end])) end++;
>  				}

landley at driftwood:~/busybox/busybox$ echo -e " 2 \n 1 \n a " | \
sort -n -k2 -t " "
 a
 1
 2
landley at driftwood:~/busybox/busybox$ echo -e " 2 \n 1 \n a " | \
./busybox sort -n -k2 -t " "
 1
 2
 a

I just added _that_ to the test suite too.

>  				/* Skip body of key */
>  				for(;str[end];end++) {
>  					if(key_separator) {
> -						if(str[end]==key_separator) break;
> +						if(str[end]==key_separator) {
> +							end++;
> +							break;
> +						}
>  					} else if(isspace(str[end])) break;
>  				}
>  			}

And that's wrong for two reasons:

1) The spec says:
> The leading field separator itself is included in a field when -t is not
> used. 

2) You're also advancing the _end_ of the key match, so you're including any 
trailing separator in this key.  (I don't know whether or not it'll cause a 
real problem, but it's icky.)

I think I fixed it, try svn 15397.

Rob
-- 
Never bet against the cheap plastic solution.