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

[Gabriel Gaster]

PS. I just read a conversation linked on Pádraig's site as a 'TODO'.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15157
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:
> > https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Sort-does-not-sort-in-normal-order_0021
> > 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?