This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The C locale

On Sep  7 21:08, Andy Koppe wrote:
> Which leaves one apparently good solution for the "C" locale:
> >> - Use the default Windows codepage for filenames, console, and
> >> multibyte functions. This is what happens already if you specifiy a
> >> locale with a language but no charset, e.g. "en". Maximum 1.5
> >> compatibility.

UTF-8 has been chosen because it has the advantage that every UTF-16
Windows filename will result in a valid multibyte string.  Every choice
has its advantage and its trade-offs.  Maximum 1.5 compatibility
(what for and how long?) vs. maximum default usability in the long run
(at least I hope so).

> On a closely related note, Debian are introducing a "C.UTF-8" locale
> as a language-neutral locale with a UTF-8 character set. This is
> useful for choosing UTF-8 without picking up language-specific stuff
> like sorting rules. See here:
> It's a rather
> lengthy thread, but in the end they did decide to go for it.

Doesn't just setting LC_CTYPE=fo_ba.UTF-8 has the same result?

> Cygwin 1.7, through newlib, already has "C-UTF-8", as well as the
> likes of "C-ISO-8859-1" or "C-SJIS". So how about replacing the "C-"
> with "C." in those, considering that Cygwin has no backward
> compatibility requirement regarding those?

No, but newlib has.  That was the only reason to keep these specifiers.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]