Subject: Re: bin/20259: sort(1) numeric sort incorrect with -kn
To: None <email@example.com (NetBSD GNATS submissions and\>
From: Giles Lean <firstname.lastname@example.org>
Date: 02/10/2003 08:37:27
Greg Woods wrote:
> 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.
No, I'm complaining that the output of sort(1) is not correctly
ordered in this case.
Per both UNIX98 and and NetBSD's manual page, -k arguments to sort can
take modifiers including 'r' and 'n'. The wording in the NetBSD
manual page is this:
When attached to a specific key (see -k), the ordering options
override all global ordering options for that key.
-n An initial numeric string, consisting of optional blank
space, optional minus sign, and zero or more digits (includ-
ing decimal point) is sorted by arithmetic value. (The -n
option no longer implies the -b option.)
-r Reverse the sense of comparisons.
In a later section it says (using the -b modifier):
m.1b refers to the first non-blank character in the mth field.
The standard is more explicit: the sort modifiers may be appended
to field specifications. From UNIX98:
The keydef argument is a restricted sort key field
definition. The format of this definition is:
where field_start and field_end define a key field restricted to
a portion of the line (see the EXTENDED DESCRIPTION section), and
type is a modifier from the list of characters b, d, f, i, n, r.
I checked a third implementation this morning: HP-UX sort(1) also
sorts the test case correctly.
I agree your example gives correct results and so is a good workaround
for the test case which has only a single -k option. Globally
specifying -r and/or -n is not a sufficient workaround in the presence
of multiple -k arguments with different ordering requirements.