Tuomo Valkonen: > Firstly Xlib/libc communication seems to be > broken/unimplemented. This has frequently been a > problem on Linux too, Xlib not being aware of libc > locales. (Xlib usually won't work without the .encoding > part in LC_CTYPE, which frequently isn't there, as > libc seemingly can get the information from elsewhere.)
If a locale is specified without an encoding, Cygwin 1.7 uses the Windows system's default "ANSI" codepage, i.e. CP1252 or such like. Presumably X implements the encodings itself rather than use setlocale(LC_CTYPE, "") and rely on the standard conversion functions? Hence, for proper interoperability, it would need to duplicate the fallback to the Windows ANSI codepage as well. Unfortunately there doesn't seem to be a standard interface for finding out what charset is being used with a locale setting that doesn't explicitly specify one. > Another problem is that a after an upgrade a couple of > months, various Python software (duplicity and eyeD3 at > least) stopped working with UTF-8 file names (and probably > other input too). This is fixed by adding the call > > locale.setlocale(locale.LC_CTYPE, "") > > in the programs. Not sure where the fault is, or if it > has been fixed by now. Strictly speaking, the default "C" locale is ASCII only, so programs shouldn't rely on anything that happens to be working on a particular system. Having said that, handling of non-ASCII characters in Cygwin's C locale has indeed changed. Not sure how and why though. See my "The C Locale" post. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
