From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Og2jY-0002G1-Gf for garchives@archives.gentoo.org; Mon, 02 Aug 2010 21:39:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F2468E09BB; Mon, 2 Aug 2010 21:39:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id DE474E095B for ; Mon, 2 Aug 2010 21:39:28 +0000 (UTC) Received: from gentoo.org (cp1107341-a.dbsch1.nb.home.nl [84.31.115.1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPSA id 1936D1B4218 for ; Mon, 2 Aug 2010 21:39:27 +0000 (UTC) Date: Mon, 2 Aug 2010 23:40:32 +0200 From: Harald van =?utf-8?Q?D=C4=B3k?= To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Locale check in python_pkg_setup() Message-ID: <20100802214032.GA1584@boostbox> References: <201007300116.43653.Arfrever@gentoo.org> <201007312211.03680.Arfrever@gentoo.org> <4C5486B6.7040408@gentoo.org> <201008022303.20713.Arfrever@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201008022303.20713.Arfrever@gentoo.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Archives-Salt: b9d94710-28f5-481c-b847-8bc20823661f X-Archives-Hash: 53c754363ee33030100859d326ffd0a4 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.