[Top][All Lists]

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

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

From: Gabriel Gaster
Subject: Re: question about behavior of sort -n -t,
Date: Tue, 8 Oct 2013 18:10:23 -0500

Thank you both very much for your detailed responses. I've responded below.

I would also like to ask that an example calling attention to this be put in 
the man pages. While the warning to use LC_ALL=C that is already there is 
helpful -- an explicit example that shows numeric sort acting differently would 
shed more light on this.

gabriel gaster

On Tuesday, October 8, 2013, Pádraig Brady wrote:
> Also note that while some of the sort funcionality is awkward,
> it's done like that for backwards and cross compatibility reasons.

That makes sense. I suppose you mean in particular that sort relies on tables 
specified by the locale?

On Tuesday, October 8, 2013, Eric Blake wrote:  
> Yes, it's a FAQ:
> and sort is doing what POSIX behaves for your particular machine's
> definitions of locales, and in turn their description of how collation
> and numeric parsing will perform in that locale. Except for the C
> locale, different vendors have tended to have different rules, even for
> locales that are otherwise named the same.  

Thanks for the FAQ, which I found very helpful. Then the question in my mind 
remains: if a user specifies a field-separator shouldn't that override the 
locale? In this case, `en_US.UTF-8' allows the comma character in numerics, 
however specifying that the comma character is a field-separator should mean it 
does not allow the comma in numerics.

It seems that the locale overrides specific arguments to sort (in this case, 
field-separator=, ). From the FAQ, I understand this might be necessarily so, 
given how sort is implemented with reference to the locale tables. Still 
though, why isn't sort faithful to an argument given to it?

reply via email to

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