default encoding (was: Re: GNU screen hangs)

[Andy Koppe <andy dot koppe at gmail dot com>]

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