1 |
On 10 Nov 2015 18:53, Mike Frysinger wrote: |
2 |
> i randomly stumbled across an ebuild that was using ^^ to make a variable |
3 |
> uppercase. this is new to bash-4.0 and thus invalid for EAPI=[0-5]. only |
4 |
> the fresh EAPI=6 permits it since we bumped the min ver to bash-4.2. |
5 |
|
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 |
but at this point, you lose most (all?) advantage to using these in the first |
18 |
place: nice & tight code. not running tr in global scope is nice too, but it's |
19 |
better all around to just hardcode something like: |
20 |
MY_PN="APINGER" |
21 |
and be done with it. |
22 |
|
23 |
thoughts ? we could add a repoman check to detect & reject usage of it, and |
24 |
for the cases where the value isn't a constant, we could add a safe helper to |
25 |
eutils like: |
26 |
tolower() { LC_COLLATE=C tr '[:upper:]' '[:lower:]'; } |
27 |
toupper() { LC_COLLATE=C tr '[:lower:]' '[:upper:]'; } |
28 |
|
29 |
yes, i'm aware that this runs the risk of mojibake when given some UTF-8 |
30 |
strings, but we already have that problem, and i don't think the uses so |
31 |
far will hit it (as people generally feed USE flags and PN values). it |
32 |
would require the C.UTF-8 locale to address. |
33 |
-mike |