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