Gentoo Archives: gentoo-dev

From: "Harald van Dijk" <truedfx@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Locale check in python_pkg_setup()
Date: Mon, 02 Aug 2010 21:39:44
Message-Id: 20100802214032.GA1584@boostbox
In Reply to: Re: [gentoo-dev] Locale check in python_pkg_setup() by Arfrever Frehtes Taifersar Arahesis
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.