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:

     -k keydef

     The keydef argument is a restricted sort key field
     definition. The format of this definition is:

     field_start[type][,field_end[type]]

     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.

Regards,

Giles