Front page | perl.perl5.porters |
Postings from September 2013
On Sun Sep 01 11:09:41 2013, sprout wrote: > 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. RT screwed it up. That appeared perfectly fine. > > 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. That is as it appeared, with question marks. -- Father Chrysostomos --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=119499Thread Previous | Thread Next