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

* faq-using.xml (faq.using.unicode): Modernize. 

(faq.api.symlinkstoppedworking): Move here from faq-api.xml.
This commit is contained in:
Corinna Vinschen 2009-03-31 10:54:28 +00:00
parent a33fa76fed
commit 7ccfe2c70e
3 changed files with 34 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
winsup/doc/ChangeLog
View File

@ -1,3 +1,8 @@
2009-03-31 Corinna Vinschen <corinna@vinschen.de>
* faq-using.xml (faq.using.unicode): Modernize.
(faq.api.symlinkstoppedworking): Move here from faq-api.xml.
2009-03-30 Dave Korn <dave.korn.cygwin@gmail.com>
* faq-using.xml (faq.using.bloda): Update with new entries.

18
winsup/doc/faq-api.xml
View File

@ -201,24 +201,6 @@ the environment variable CYGWIN.
</para>
</answer></qandaentry>
<qandaentry id="faq.api.symlinkstoppedworking">
<question><para>Why do some of my old symlinks don't work anymore?</para></question>
<answer>
<para>Beginning with Cygwin 1.7, Cygwin supports multiple character sets.
Symlinks created with Cygwin 1.7 are using the UTF-16 character set, which is
portable across all character sets. Old symlinks were written using your
current Windows codepage, which is not portable across all character sets.
If the target of the symlink doesn't resolve anymore, it's very likely that
the symlink points to a target filename using native, non-ASCII characters,
and you're now using another character set than way back when you created
the symlink.</para>
<para>Solution: Delete the symlink and create it again under you new Cygwin.
The new symlink will be correctly point to the target no matter what character
set you're using in future.</para>
</answer></qandaentry>
<qandaentry id="faq.api.executables">
<question><para>Why do some files, which are not executables have the 'x' type.</para></question>
<answer>

48
winsup/doc/faq-using.xml
View File

@ -367,19 +367,15 @@ formfeed character to your file.
<answer>
<para>Internationalization is a complex issue. The short answer is that
Cygwin relies on the setting of the CYGWIN environment variable as well
as on the setting of LANG/LC_xxx environment variables.</para>
Cygwin relies on the setting of the setting of LANG/LC_xxx environment
variables.</para>
<para>To get UTF-8 support you must set the environment variable CYGWIN
so that it contains the substring "codepage:utf8". This is required in
Cygwin so far to get correct translation from Windows wide character
filenames to their UTF-8 counterpart. Applications on the other hand
require the setting of the LANG, LC_ALL, or LC_CTYPE environment variables.
To get UTF-8 support you can set, for instance, $LANG to "en_US.UTF-8".
This will give you support for the UTF-8 character set. Note that the
language part has to contain a valid language specifier, but is otherwise
so far ignored by newlib, the underlying C library. There's no support
for correct language-specific collation, monetary or date/time-related
<para>To get UTF-8 support you must set the LANG, LC_ALL, or LC_CTYPE
environment variables. To get UTF-8 support you can set, for instance,
$LANG to "en_US.UTF-8". This will give you support for the UTF-8 character
set. Note that the language part has to contain a valid language specifier,
but is otherwise so far ignored. There's no support for correct
language-specific collation, monetary or date/time-related
string handling. This is planned for a later release, though.</para>
<para>To type international characters (&pound;&auml;&ouml;) in
@ -391,23 +387,19 @@ string handling. This is planned for a later release, though.</para>
set convert-meta off
set output-meta on
set input-meta on
set kanji-code sjis
</screen>
<para>These are options to the <literal>readline</literal> library, which
you can read about in the <literal>bash(1)</literal> and
<literal>readline(3)</literal> man pages. Other tools that do not use
<literal>readline</literal> for display, such as <literal>less</literal>
and <literal>ls</literal>, require additional settings, which could be put
in your <literal>~/.bashrc</literal>:
and <literal>ls</literal>, might require additional settings for doublebyte
or multibyte charsets, which could be put
in your <literal>~/.bashrc</literal>, for instance:
<screen>
alias less='/bin/less -r'
alias ls='/bin/ls -F --color=tty --show-control-chars'
export LANG="ja_JP.SJIS"
export OUTPUT_CHARSET="sjis"
</screen>
These examples use the Japanese Shift-JIS character set, obviously
you will want to change them for your own locale.
</para>
</answer></qandaentry>
@ -975,6 +967,24 @@ Cygwin application providing a native GUI.
</para>
</answer></qandaentry>
<qandaentry id="faq.api.symlinkstoppedworking">
<question><para>Why do some of my old symlinks don't work anymore?</para></question>
<answer>
<para>Beginning with Cygwin 1.7, Cygwin supports multiple character sets.
Symlinks created with Cygwin 1.7 are using the UTF-16 character set, which is
portable across all character sets. Old symlinks were written using your
current Windows codepage, which is not portable across all character sets.
If the target of the symlink doesn't resolve anymore, it's very likely that
the symlink points to a target filename using native, non-ASCII characters,
and you're now using another character set than way back when you created
the symlink.</para>
<para>Solution: Delete the symlink and create it again under you new Cygwin.
The new symlink will be correctly point to the target no matter what character
set you're using in future.</para>
</answer></qandaentry>
<qandaentry id="faq.using.symlinks-samba">
<question><para>Why don't symlinks work on samba-mounted filesystems?</para></question>
<answer>