On 08/10/2017 05:37 PM, Bruno Haible wrote: >> You still want a sane fallback for all the categories that you are not >> explicitly setting. It's harder to type: >> >> LANG=C LC_CTYPE=C.UTF-8 env -u LC_ALL foo > > or: > LANG=C LC_CTYPE=C.UTF-8 LC_ALL= foo
If setting LC_ALL to empty forces fallback, then that is indeed easier than explicitly unsetting it. Still, if we are advocating mixed locale execution, we MUST ensure sane defaults for ALL of the LC_* variables. So even if you are advocating for keeping LC_ALL set, we should STILL sanitize LANG and all the other LC_* variables (either unset them, or set them to C). The above command line will not work if LC_MESSAGES is still set to some other locale, particularly one not encoded in UTF-8. > In the big picture, I find the current situation more maintainable and robust: > Everyone knows that when specifying a "mixed" locale they need to set all > of LC_ALL, LC_<category>, and LANG. Not just the LC_<category> they are overriding, but every other LC_<category> as well. > > Whereas in the world you are depicting, you would be doing half of a > mixed locale specification and depending on maint.mk to do the other half. > Call it "dependency" or call it "distributed responsibility" - in any > case it would require coordination and reduce the freedom of action > for the maintainers of maint.mk. But the command lines with the distributed responsibility are longer, so having sane defaults IS worth having. Maybe you can still argue that the sane default should include LC_ALL=C, but that does NOT mean that the sane default can overlook the other tiers. > > In particular, you don't even have a guarantee that LANG=C and > LC_CTYPE=C.UTF-8 > fit well together. (It might work on some libcs and fail on others.) We already have problems with Python refusing to import UTF-8 data in LC_ALL=C environments (which is arguably a bug in python, since POSIX says locale "C" is 8-bit clean and therefore cannot cause encoding errors). C.UTF-8 does not exist everywhere, but does appear to shut up the python problem when mixed with LANG=C, at least on the platforms where the problems are encountered in the first place. > With your > proposal, we don't have a clear responsibility: it's not clear whether > the setting of LANG=C by maint.mk or the setting of LC_CTYPE=C.UTF-8 is to > be changed. I think maint.mk should still default to the C locale, but make it easy to do a mixed-locale override. With LANG set and all other tiers cleared, mixed-locale overrides are easy; but with LC_ALL set, an override has to worry about all three tiers. > > Which is why I prefer the current situation, without mixed or intertwined > responsibilities. > > Bruno > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
