[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:34:16 -0500

PS. I just read a conversation linked on Pádraig's site as a 'TODO'.
GNU bug report logs - #15157 join doesn't follow norms and dies instead of 
doing something useful w/duplicate options

While I'm not sure, it seems that this might be a related conversation -- 
regarding command-line specified arguments overriding environment settings. I 
read pieces from that exchange but I couldn't determine if the todo is to allow 
the command-like specified field-separator to override settings in LC_* or not.

Thank you.

On Tuesday, October 8, 2013 at 6:10 PM, Gabriel Gaster wrote:

> 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]