On Tue, 23 Dec 2003, Jarkko Hietaniemi wrote: > > I don't see how introducing a new LC_* would help here. Whether > > Limit the mess of CTYPE controlling Yet Another Feature.
I don't think it's yet another feature. It's one of features that's commonly assigned to it. Well, I guess you'd ask how 'commonly'... Anyway, introducing a new env. variable is not a solution to the mess. By doing so, you just add another problem because a new variable is only meaningful to Perl at least at the beginning. > > it's LC_CTYPE or LC_FILENAME, the problem is still there. > > > to and from the codeset returned by 'nl_langinfo(CODESET)'. > > Don't get me started how suckily and brokenly nl_langinfo() is supported > across platforms :-) Well, CODESET may be on the average better > supported. > May. nl_langinfo(CODESET) is rather well supported where it's available (i.e. SUS-compliant modern Unix platforms). Encoding/codeset name mess is another issue, though. If Perl could use gnulib (a collection of small code snippets that are meant to be included in the source code, 'nl_langinfo(CODESET)' could be emulated where it's not available. However, I guess it can't because GPL/LGPL is not suitable for Perl according to you. > > Directly inspecting LC_CTYPE or other environment variables is a BAD > > idea > > I can optimize that for ya: s/Directly inspecting/Using/ :-) I intentionally used the phrase because 'nl_langinfo(CODESET)' is 'the' _indirect_ way to get to it (plus the resolution of LC_*/LANG environment variable priority) Jungshik
