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
