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:


    Specifies the minimal environment for C-language translation called the
    POSIX locale.  The POSIX locale is the default global locale at entry to
    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.

Reply via email to