libs/newlib-cygwin
libs
/
newlib-cygwin
mirror of git://sourceware.org/git/newlib-cygwin.git
4
0
Fork 0
Code Issues Projects Releases Wiki Activity

* pathnames.sgml (pathnames-unusual): Talk about using UTF-8 in C 

locale.
	* setup2.sgml (setup-locale-problems): Ditto.
This commit is contained in:
Corinna Vinschen 2009-05-13 15:11:39 +00:00
parent b6c6ea43f3
commit 40c66067fb
3 changed files with 18 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
winsup/doc/ChangeLog
View File

@ -1,3 +1,9 @@
2009-05-13 Corinna Vinschen <corinna@vinschen.de>
* pathnames.sgml (pathnames-unusual): Talk about using UTF-8 in C
locale.
* setup2.sgml (setup-locale-problems): Ditto.
2009-05-06 Corinna Vinschen <corinna@vinschen.de>
* faq-setup.xml: Fix entry explaing how the homedir is evaluated

5
winsup/doc/pathnames.sgml
View File

@ -368,6 +368,11 @@ filename because the question mark will not translate back to the original
Chinese character, but to a simple question mark instead. This in turn
results in strange "File not found" messages.</para>
<note><para>In the default "C" locale, Cygwin creates filenames using
the UTF-8 charset. This will always result in some valid filename by
default, but again might impose problems when switching to a non-"C"
or non-"UTF-8" charset.</para></note>
<note><para>To avoid this scenario altogether, always use UTF-8 as the
character set.</para></note>

11
winsup/doc/setup2.sgml
View File

@ -317,12 +317,15 @@ variable hasn't been set <emphasis>before</emphasis> starting this process,
Cygwin has to make an educated guess which charset to use to convert
the environment itself. The only reproducible way to do that in the absence
of <envar>LC_ALL</envar>, <envar>LC_CTYPE</envar>, or <envar>LANG</envar>,
is to use the current Windows ANSI codepage.</para>
is to use the "C" locale. The default conversion in the "C" locale
used by Cygwin internally is UTF-8. So, in the absence of any
internationalization environment variable, the environment will be converted
to UTF-8.</para>
<para>As long as the environment only contains ASCII characters, this is
no problem. But if it contains native characters, and you're planning
to use, say, UTF-8, the environment will result in invalid characters in
the UTF-8 charset. This would be especially a problem in variables like
no problem at all. But if it contains native characters, and you're planning
to use, say, GBK, the environment will result in invalid characters in
the GBK charset. This would be especially a problem in variables like
<envar>PATH</envar>.</para>
<note><para>Per POSIX, the name of an environment variable should only