On Sat, Mar 09, 2002 at 11:59:29AM -0800, Larry Wall wrote:
In Markus's lovely http://www.cl.cam.ac.uk/~mgk25/unicode.html document,
he writes:
On POSIX systems, the selected locale identifies already the encoding
expected in all input and output files of a process.
Perl currently violates this, and I'm getting very tired very quickly
of having to put things like
eval {
binmode IN, ":utf8";
binmode STDIN, ":utf8";
binmode STDOUT, ":utf8";
};
in my programs, despite running in a LANG=en_US.UTF-8 locale with a
UTF-8 aware xterm and a UTF-8 aware editor. What will it take to fix
that? Not much, I think.
I started doing this at one point by making Perl to understand the
langinfo(CODESET) thingy (I18N::Langinfo), but at some point I was
somewhat disheartened by the sucky support of langinfo() across the
platforms and walked away in disgust.
However, one can even currently (in 5.7.3) say use open ':locale' and
if your langinfo() returns something matching /utf-?8/i you will get
automagic utf8-fication on your I/O (Not on your STDIN and OUT,
though). At least, that was the theory and plan.
Markus, what's your take on this? Do you think open by default should
try to Do the Right Thing? I'm trying to balance out the needs of
neophytes with experts here. Perhaps this is another of those things
that should work differently under C<use strict>. But it's so
pitifully easy to distinguish UTF-8 from ISO-8859-1 that it seems like
that should almost be mandatory.
But the first step is recognizing UTF-8 locales.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
