On Wed, 11 Nov 2015 07:16:42 +0100 Patrick Lauer <[email protected]> wrote:
> On 11/11/2015 03:51 AM, Mike Frysinger wrote:
> > On 10 Nov 2015 18:53, Mike Frysinger wrote:
> >> i randomly stumbled across an ebuild that was using ^^ to make a variable
> >> uppercase. this is new to bash-4.0 and thus invalid for EAPI=[0-5]. only
> >> the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2.
> > Arfrever highlights these are not even safe to use. bash is locale aware,
> > so it'll apply LC_COLLATE rules when processing the ^/, casemods. while
> > you can fix this with external programs ala:
> > LC_COLLATE=C tr ...
> >
> > you can't do it with inline code like:
> > LC_COLLATE=C SRC_URI=".../${PN^^}/..."
> >
> > you can if you do something like:
> > SRC_URI=".../$(LC_COLLATE=C; echo "${PN^^}")/..."
> >
> This points out a class of problems we've hit in the past: locale-aware
> things in ebuilds.
>
> 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.?
>
> (And as a side-effect the build logs are always readable ;) )
Pretty much +1 here. Not saying we need to force full locale, but
having sane LC_CTYPE and LC_COLLATE would make sense. PMS already
forces it in a few places... we may as well force it globally.
--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>
pgpGdo_o0JD6v.pgp
Description: OpenPGP digital signature
