Subject: Re: bin/20259: sort(1) numeric sort incorrect with -kn
To: NetBSD GNATS submissions and followups <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 02/10/2003 16:44:58
[ On Monday, February 10, 2003 at 16:07:41 (-0500), Greg A. Woods wrote: ]
> Subject: Re: bin/20259: sort(1) numeric sort incorrect with -kn
> [ On Monday, February 10, 2003 at 08:37:27 (+1100), Giles Lean wrote: ]
> > Subject: Re: bin/20259: sort(1) numeric sort incorrect with -kn
> > 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.
> Apples and oranges! NetBSD's sort(1) implements only:
> -k field1[,field2]
> Designates the starting position, field1, and optional ending
> position, field2, of a key field. The -k option replaces the
> obsolescent options +pos1 and -pos2.
> No claims are made about standards compatability.
OK, I see deeper in the manual page some more verbiage that does suggest
support for the [type] option in a field-spec:
The arguments field1 and field2 have the form m.n and can be followed by
one or more of the letters b, d, f, i, n, and r, which correspond to the
options discussed above. A field1 position specified by m.n (m, n > 0)
is interpreted as the nth character in the mth field. A missing .n in
field1 means `.1', indicating the first character of the mth field; if
the -b option is in effect, n is counted from the first non-blank charac-
ter in the mth field; m.1b refers to the first non-blank character in the
Sorry for the confusion. The manual page really does need to be fixed
up to look more like the UNIX98 spec.
Now we know that either the setfield() routine is not parsing the [type]
option properly, or at least is not applying the result to the flags
controlling the sorting algorithms.
Greg A. Woods
+1 416 218-0098; <firstname.lastname@example.org>; <email@example.com>
Planix, Inc. <firstname.lastname@example.org>; VE3TCP; Secrets of the Weird <email@example.com>