Ruby » Ruby 1.8

I noticed issues with other things, like puts, print and such.

Most of the File and IO functions for Windows are ANSI, not Wide, which limits the options to process properly paths, filenames and even output of strings using UTF/Unicode characters.

Also, the console page affects ruby. By default is 437, but 1252 is needed to get accented strings to work.

Further review of the used Windows API is needed to find these issues.

This is bug or feature? :)

I hope that this behavior in Windows would be corrected in the
new versions of Ruby.

Is there a workaround for this bug?

Also, there are cp1251 for Russian, not cp1252.

Both cp1251 and cp1252 are ASCII extensions from Microsoft, and Ruby 1.8 assumes strings are all ASCII unless you use multibyte gem or activesupport. So try that and if you can get it working in console (windows console, not irb) with mkdir, you can try using Kernel#system.

Well, since for Ruby cyrillic characters are integers (just like any others), it uses integer values and Windows does not normalize them (OS X does, for instance). I see no way to fix this in 1.8.x branch and in 1.9 you already have encoding-aware strings, IO objects and so forth. But I am by no means M17N expert and may be wrong.

Okay, thanks.

Perhaps I should take into view this behaviour in the Windows until
Ruby 1.9 (or 2.0?) becomes stable.

1.9.1 branch is stable for day-to-day use, I do not know about any available builds for Windows though, and some libraries you may want to use still need to catch up. v1_8_0 tag of Ruby is from 2003 and Windows XP is from 2001 or so. At some point in time, people should consider moving on or just accept what is missing in older versions. Ruby is not unique in this regard.

It is impossible to jump into 1.9.x, because I use Shoes,
which is compiled by _why with Ruby 1.8.x.

So I can not build Shoes with a new Ruby for every operating
system that supported by Shoes.

well, maybe others can help, why don't you ask at shoes mailing list?

Because the bug, described here, doesn't applies especially to Shoes:
many other specific applications (that works in Win32 and operating
with environment variables and with file system entirely) has a
encoding-misunderstanding problem.

I found a dirty workaround: application should place its own folder
into %CommonProgramFiles%/AppName, instead of
%USERPROFILE%/Application Data/AppName.

This method has one disadvantage: data, which stored by application,
is available to everybody. I'm sorry for offtopic.

Issue should be closed, thanks for your time, comments and tips.

Similar situation with print of encoded characters happened to Cucumber developers:

http://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/81

They ended using chcp and Iconv to do the character conversion back and forth.