[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Coreutils Command "sort" Needs Manual Clarity

From: Pádraig Brady
Subject: Re: Coreutils Command "sort" Needs Manual Clarity
Date: Wed, 5 Mar 2008 00:14:23 +0000
User-agent: Thunderbird (X11/20071008)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]