| 1 |
On 11/11/2015 03:51 AM, Mike Frysinger wrote: |
| 2 |
> On 10 Nov 2015 18:53, Mike Frysinger wrote: |
| 3 |
>> i randomly stumbled across an ebuild that was using ^^ to make a variable |
| 4 |
>> uppercase. this is new to bash-4.0 and thus invalid for EAPI=[0-5]. only |
| 5 |
>> the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2. |
| 6 |
> Arfrever highlights these are not even safe to use. bash is locale aware, |
| 7 |
> so it'll apply LC_COLLATE rules when processing the ^/, casemods. while |
| 8 |
> you can fix this with external programs ala: |
| 9 |
> LC_COLLATE=C tr ... |
| 10 |
> |
| 11 |
> you can't do it with inline code like: |
| 12 |
> LC_COLLATE=C SRC_URI=".../${PN^^}/..." |
| 13 |
> |
| 14 |
> you can if you do something like: |
| 15 |
> SRC_URI=".../$(LC_COLLATE=C; echo "${PN^^}")/..." |
| 16 |
> |
| 17 |
This points out a class of problems we've hit in the past: locale-aware |
| 18 |
things in ebuilds. |
| 19 |
|
| 20 |
Wouldn't it be 'easier' (fsov easy) to have portage use sane-default |
| 21 |
locale settings, so that estonian or turkish users don't get hit by |
| 22 |
weirdness in the [a-z] character class etc.? |
| 23 |
|
| 24 |
(And as a side-effect the build logs are always readable ;) ) |
Archives