Front page | perl.perl5.porters |
Postings from September 2013
On Sun Sep 01 09:24:19 2013, public@khwilliamson.com wrote: > On 08/31/2013 10:36 PM, Karl Williamson wrote: > > I feel compelled to point out that this code is buggy. > I18N::Langinfo > > is not portable to all platforms that Perl runs on, and CODESET > gives > > the locale of LC_CTYPE, which may not be the same locale that $! is > > returned in: LC_MESSAGES. (Note that the code could be modified to > > change LC_CTYPE to the locale of LC_MESSAGES temporarily around the > > langinfo call to addess this bug.) Also, some vendors' > nl_langinfo() > > was, at the time, so buggy that the core .t for this doesn't do any > > "real" testing. > > http://perl5.git.perl.org/perl.git/blame/HEAD:/ext/I18N- > Langinfo/t/Langinfo. > > I now feel compelled to point out that I should have been more clear > that this code is fine, not buggy, if used in the environment in which > it was likely designed for. On a platform with a working > nl_langinfo() > and the programmer knows that LC_MESSAGES and LC_CTYPE are always in > sync, this worked well, until I broke it. More importantly, as Victor pointed out, it breaks programs that are not trying to do anything with character sets or locales, such as ack, when they are running on a utf8 terminal in a utf8 locale. I dare to bet those are the most common. On dromedary I get this with the system perl (5.12.3): $ LC_ALL=hu_HU.utf8 perl -e 'open "oentuheon" or die $!' Nincs ilyen fájl vagy könyvtár at -e line 1. When I build my own (blead)perl, I get this: $ LC_ALL=hu_HU.utf8 ./perl -e 'open "oentuheon" or die $!' Nincs ilyen f?jl vagy k?nyvt?r at -e line 1. -- Father Chrysostomos --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=119499Thread Previous | Thread Next