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^^}")/..."
but at this point, you lose most (all?) advantage to using these in the first
place: nice & tight code. not running tr in global scope is nice too, but it's
better all around to just hardcode something like:
MY_PN="APINGER"
and be done with it.
thoughts ? we could add a repoman check to detect & reject usage of it, and
for the cases where the value isn't a constant, we could add a safe helper to
eutils like:
tolower() { LC_COLLATE=C tr '[:upper:]' '[:lower:]'; }
toupper() { LC_COLLATE=C tr '[:lower:]' '[:upper:]'; }
yes, i'm aware that this runs the risk of mojibake when given some UTF-8
strings, but we already have that problem, and i don't think the uses so
far will hit it (as people generally feed USE flags and PN values). it
would require the C.UTF-8 locale to address.
-mike
signature.asc
Description: Digital signature
