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>