Subject: Re: bin/20259: sort(1) numeric sort incorrect with -kn
To: None <giles@nemeton.com.au>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 02/09/2003 15:53:40
[ On , February 9, 2003 at 18:16:09 (+1100), giles@nemeton.com.au wrote: ]
> Subject: bin/20259: sort(1) numeric sort incorrect with -kn
>
> 	sort(1) fails to sort correctly when -k and -n are used together.

I presume you're complaining only about the lack of command-line syntax
error reporting, since indeed there's no actual bug in sort(1) -- just a
usage issue.

> >How-To-Repeat:
> 	# following output is incorrect
> 	$ echo "1\n0" | sort -k1rn
>         0
>         1

	$ echo "1\n0" | sort -k 1 -rn 
	1
	0

 
> 	This is a simplified test case.  The original came from arch:
> 
>         # incorrect
>         $ printf "0.0.hello-world--mainline--0.0\n0.1.hello-world--mainline--0.1" \
> 	> | sort -t. -k2rn
>         0.0.hello-world--mainline--0.0
>         0.1.hello-world--mainline--0.1

	$ printf "0.0.hello-world--mainline--0.0\n0.1.hello-world--mainline--0.1" | sort -t . -k 2 -rn
	0.1.hello-world--mainline--0.1
	0.0.hello-world--mainline--0.0

I agree that getting incorrect results instead of the proper error
message is wrong....

The problem is no doubt rooted in getopt(2) being a lot too lax.  In
theory the value of `optarg' for `-k' should be "2rn", even with the
relaxed getopt() syntax checking allowing for no space after the '-k',
and that should have caused the setfield() function to fail due to an
invalid field-spec.  Actually maybe setfield() did fail, silently, since
of course the code fails to check for errors on its return.....  That
would also explain why the '-r' and '-n' appear to be ignored.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>