Re: locale in ruby

In article <6.0.0.20.2.20080101181120.082f1b30@localhost>,
  Martin Duerst <[e-mail]> writes:

> But now try switching to e.g. a Turkish locale
> (the example that follows is on a Fedora box with tcsh,
> your mileage may vary):
>
> $ setenv LANG tr_TR.iso88599
> $ ruby -e "puts 'abc'.force_encoding('US-ASCII').encoding"
> -e:1:in `force_encoding': unknown encoding name - US-ASCII (ArgumentError)
>         from -e:1:in `<main>'

Great example.  Thank you.  I fixed.

Do you know other problems?

> If you set your locale before invoking irb, you might.

I confirmed it on Debian GNU/Linux 4.0 (Etch).

% LANG=tr_TR.ISO-8859-9 bin/irb
irb(main):001:0> RUBY_VERSION
=> "1.8.6"
irb(main):002:0> RUBY_PLATFORM
=> "i686-linux"
irb(main):003:0> "i".upcase
=> "\335"
irb(main):004:0> "I".downcase
=> "\375"
irb(main):005:0> 

You are right.  "i".upcase is "\335" under tr_TR.ISO-8859-9.

> As I said earlier, if we want to keep setlocale, we have
> to check every libc call for locale effects. I looked around
> for strcasecmp, which I knew changes behavior in some locales.
> There are quite a few strcasecmp in Ruby. Some are harmless
> (e.g. checking for ".exe" in ruby.c, because there are no
> locales where '.', 'e', or 'x' are treated differently).
> Others are dangerous. Sometimes it may be difficult to
> figure out what's the right way to do, because some
> Turkish systems may e.g. use Turkish rules for case
> correspondence of environment variables, while other
> systems may use basic C locale rules.

I replaced such functions by locale-independent version.

Do you have an example that locale-indepenedent function
causes a problem?
-- 
Tanaka Akira