I'd be in favor of full-on LC_ALL=C. Ebuilds are meant for having a
particular determinism. They're machine scripts. The operations they do
need to be consistent.
For user-facing parts, such as printing information, or sorting user-shown
text, I can understand ebuild authors might want in some special
circumstances to run a command with the user's language. For that reason,
what if we did this:
USER_LANG="$LANG"
unset LANG ${!LC_*}
export LC_ALL=C
That way, ebuild writers could do:
LC_ALL="$USER_LANG" einfo "Blah blah $(sort <blah)"
While the rest of the actual programmatic part of the ebuild functions
deterministically with LC_ALL=C.
This seems like a decent compromise...
On Nov 11, 2015 4:49 PM, "Ulrich Mueller" <[email protected]> wrote:
> >>>>> On Wed, 11 Nov 2015, Ciaran McCreesh wrote:
>
> > On Wed, 11 Nov 2015 07:16:42 +0100
> > Patrick Lauer <[email protected]> wrote:
> >> Wouldn't it be 'easier' (fsov easy) to have portage use sane-default
> >> locale settings, so that estonian or turkish users don't get hit by
> >> weirdness in the [a-z] character class etc.?
>
> > Paludis forces all the LC variables to sane values. A few vocal
> > annoying users hate this, and patch it out...
>
> Unfortunately, that doesn't help us, since ebuilds cannot rely on it.
>
> Should we revise EAPI 6? It hasn't been cleared for usage in the tree
> yet, so should be still possible. Losing such an important feature of
> bash-4 seems to be reason enough. (And obviously, some people had been
> aware of the problem. Why did nobody speak up before the spec was
> approved?)
>
> Paludis seems to do this:
>
> unset LANG ${!LC_*}
> export LC_ALL=C
>
> We could just add this to the spec. Alternatively, something less
> intrusive, like setting only LC_COLLATE and LC_CTYPE.
>
> We already have LC_MESSAGES=C in the base profile, per 20130813
> Council decision.
>
> Ulrich
>
