[Top][All Lists]

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

Re: question about behavior of sort -n -t,

From: Eric Blake
Subject: Re: question about behavior of sort -n -t,
Date: Tue, 08 Oct 2013 19:48:39 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

On 10/08/2013 05:10 PM, Gabriel Gaster wrote:

[Can you convince your mailer to wrap long lines? It would make it
easier for me to reply]

>  the question in my mind remains: if a user specifies a field-separator 
> shouldn't that override the locale?

No, because POSIX requires that -n parse as many characters as possible
regardless of locale, unless you explicitly ask to limit the sort to a
specific key.

Perhaps less likely to be used in real life, but still apropos to the

$ printf '1202\n2011\n' | LC_ALL=C sort --debug -t0 -s -n -k1,1
sort: using simple byte comparison

$ printf '1202\n2011\n' | LC_ALL=C sort --debug -t0 -s -n
sort: using simple byte comparison

And you'll get the same behavior on Solaris or BSD sort (at least,
assuming they don't have blatant POSIX compliance bugs).  Once you
understand WHY the above example has two different sorts, based on
whether -k is used, you'll understand why we can't stop parsing -n at a
comma even for -t, in a non-C locale.

> It seems that the locale overrides specific arguments to sort (in this case, 
> field-separator=, ).

Rather, the lack of -k determines how far -n will parse, regardless of
locale; it's just that some locales let -n parse farther than others.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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