Mail Archives: cygwin/2009/09/08/15:35:21
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:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522776. 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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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
- Raw text -