[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'.
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?
- question about behavior of sort -n -t,, Gabriel Gaster, 2013/10/08
- Re: question about behavior of sort -n -t,, Eric Blake, 2013/10/08
- Re: question about behavior of sort -n -t,, Pádraig Brady, 2013/10/08
- Re: question about behavior of sort -n -t,, Eric Blake, 2013/10/08
- Re: question about behavior of sort -n -t,, Gabriel Gaster, 2013/10/09
- Re: question about behavior of sort -n -t,, Gabriel Gaster, 2013/10/09
- Re: question about behavior of sort -n -t,, Eric Blake, 2013/10/09
- Re: question about behavior of sort -n -t,, Gabriel Gaster, 2013/10/09