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?
