Re: Console codepage setting via chcp?

[IWAMURO Motonori <deenheart at gmail dot com>]

2009/9/28 Corinna Vinschen <corinna-cygwin@cygwin.com>:
>> > - System objects will always be *initially* translated using UTF-8. This
>> > Âincludes file names, user names, and initial environment variables.
>> > - By setting the locale environ variables you can switch the charset
>> > Âused to translate filenames on a per-process base.
>> > ÂThis would be only a stop-gap measure, to allow to re-use old archives
>> > Âor scripts. ÂThose should be converted to UTF-8 ASAP. ÂExpect complaints.
>
> Basically, either the above, or just always UTF-8 for filenames
> everywhere, every time. ÂI have a local implementation now which
> behaves according to the above proposal.

My opinion:
I think that mb*/wc*/ctypes functions should accept any 8bit byte data
when use C locales.
In other words, the charset of C.<charset> should affect only
filenames and console I/O.
I uncommonly use LANG=C to treat the content in file/stream as 8bit byte data.

>> > - The "C" locale's charset will be UTF-8.
>> > - There'll be language-neutral "C.<charset>" locales.
>> > - The user's ANSI codepage will remain the default charset for
>> > "language_TERRITORY" locales.
>> > - The console charset will be set according to LC_ALL/LC_CTYPE/LANG
>> > Âat the time the application starts.
>>
>> * Is other issue of existing only the thread "Lone surrogates in UTF-8?"?
>> Â(Does the thread exist in the ML archive page?)
>
> Sorry, I don't understand the question. ÂBut, yes, the thread exists
> in the cygwin-developers mailing list archives.

Excluding above issues, any problem exists?
(Please forget the question in parentheses)
-- 
IWAMURO Motnori <http://vmi.jp/>