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


2009/9/8 Corinna Vinschen:
>> 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.

Fair enough, if the console and the character conversion functions
used UTF-8 as well (and if applications such as mc, nano and mutt were
rebuilt with UTF-8 support).

Unfortunately, they use ISO-8859-1, so out-of-the box the support for
non-ASCII characters in Cygwin 1.7 is effectively broken. Please see
posts earlier in this thread for the problems caused by this.

Yes, users can set a locale variable to get this working, but hacking
Cygwin.bat or finding the Windows environment variable dialog isn't
exactly intuitive. And they didn't have to do that in 1.5 to at least
get the Windows "ANSI" codepage working.


>ÂEvery choice has its advantage and its trade-offs.

The current choices have nothing but disadvantages, due to mixing of
UTF-8 and ISO-8859-1.

Besides, regarding the Windows codepage, wasn't the ^N scheme
introduced to deal with filename characters outside the current
charset?


>> 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?

For newlib, yes, because it doesn't (yet) care about the language
part. But the language part nevertheless matters for many programs,
and it may also matter when connecting to other hosts, e.g. by
changing the sort order in 'ls'.

"C.charset" would mean: give me all the default behaviours, except
that I want this specific charset.


>> 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.

Understood. I meant a __CYGWIN__-guarded change.

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


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