On Mon, Aug 02, 2010 at 11:02:20PM +0200, Arfrever Frehtes Taifersar Arahesis
wrote:
> It would have to be parsed using e.g. grep and sed. It's easier to call
> Python in this case.
It's even easier not to.
> The call to Python is sufficiently fast:
>
> $ time python -c 'import os; print(os.environ.get("LC_ALL",
> os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"))))' > /dev/null
>
> real 0m0.062s
> user 0m0.051s
> sys 0m0.011s
Let's compare. On my system:
time python -c 'import os; print(os.environ.get("LC_ALL",
os.environ.get("LC_CTYPE", os.environ.get("LANG", "POSIX"))))'
en_GB.UTF-8
real 0m0.020s
user 0m0.016s
sys 0m0.004s
time sh -c 'echo "${LC_ALL:-${LC_CTYPE:-${LANG:-POSIX}}}"'
en_GB.UTF-8
real 0m0.001s
user 0m0.000s
sys 0m0.000s
And that's after several runs for both, so it's not caused by the
initial load of python, which wasn't in memory yet.
Yes, 0.019s is very little, but in this case I see absolutely no benefit
whatsoever in calling python. Plus sh has the advantage of actually
working when LC_ALL is exported as "" (which in LC_* means the same as
having it unset)...
But why exactly are you concerned about LC_* being defined but not
exported anyway? You're checking from an ebuild; locales are going to
get inherited from portage or profile.env anyway, so you can just
assume that if they _are_ set, they're exported. The only way they might
not be is if the user is messing with the locale from the bashrc, and if
the user's doing that, the user really needs to fix the bashrc and
export the vars anyway.
None of this changes the fact that locale checks warns about bugs in packages,
not bugs in the user's configuration.
