Re: Coreutils Command "sort" Needs Manual Clarity

[Pádraig Brady]

Tony Kocurko wrote:
> Hi, All...
> 
>  It might be that the man page for sort needs some
> polishing. I discovered that in the "-k F[.C],F[.C]"
> command line argument pair, for fields beyond the
> first, the first character appears to be the first
> delimiter character prior to the field.

That (confusing default) is documented in the man page:

"If neither -t nor -b is in effect, characters in a field
are counted from the beginning of the preceding whitespace."

> # cat SortProblem1
> ABC 010201
> DEF 010202
> GHI 020203
> JKL 010204
> MNO 010208
> PQR 010301
> STU 010302
> 
> [First I thought it should be:]
> sort -k 2.5,2.6n -k 2.1,2.2n -k 2.3,2.4n
> [then I realised it should be:]
> sort -k 2.6,2.7n -k 2.2,2.3n -k 2.4,2.5n

Since all fields are the same type you can
simplify it further to:

sort -bn -k2.5,2.6 -k2.1,2.2 -k2.3,2.4

In fact because this is fixed with data you
don't need to convert to numeric for comparison at all,
and you know this will only be ASCII data so
you can tell sort to use the fast "C" data comparison:

LC_ALL=C sort -b -k2.5,2.6 -k2.1,2.2 -k2.3,2.4

Note a subtlety with specifying the global -b option
is also documented in the man page:

"OPTS is one or more single-letter ordering options,
which override global ordering options for that key."

That means that if you do need to change the sort type
for a specific field, then you will need to also specify the
b option again to both positions.

Pádraig.