On Thu, Feb 07, 2019 at 04:08:21PM +0100, Ansgar wrote: > On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote: > > POSIX specifies the output format for various utilities in the C locale, > > which defeats my understanding of the purpose of this proposal. So, for > > example, in ls -l: > > I don't think the "C.UTF-8" locale covered by any promises POSIX might > make for "C". (Nor is what happens when no LC_*, LANG vairables are > set at all.)
Here's the latter: http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html "POSIX" Specifies the minimal environment for C-language translation called the POSIX locale. The POSIX locale is the default global locale at entry to main(). "C" Equivalent to "POSIX". "" Specifies an implementation-defined native environment. [CX] The determination of the name of the new locale for the specified category depends on the value of the associated environment variables, LC_* and LANG; see XBD Locale and Environment Variables. So a process that doesn't call setlocale() at all must work within the requirements of "C" (which C.UTF-8 almost meets standards-wise, but too many programs misinterpret as raw 8-bit for a switch to be safe) -- but a process that _does_ call setlocale("") when the env vars are unset may get anything reasonable. I argue that C.UTF-8 is more reasonable than "C". -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄⠀⠀⠀⠀