diff --git a/winsup/doc/ChangeLog b/winsup/doc/ChangeLog index 74a38458a..830a233c1 100644 --- a/winsup/doc/ChangeLog +++ b/winsup/doc/ChangeLog @@ -1,3 +1,8 @@ +2009-03-31 Corinna Vinschen + + * faq-using.xml (faq.using.unicode): Modernize. + (faq.api.symlinkstoppedworking): Move here from faq-api.xml. + 2009-03-30 Dave Korn * faq-using.xml (faq.using.bloda): Update with new entries. diff --git a/winsup/doc/faq-api.xml b/winsup/doc/faq-api.xml index 2f7a9f15a..ff6ef2052 100644 --- a/winsup/doc/faq-api.xml +++ b/winsup/doc/faq-api.xml @@ -201,24 +201,6 @@ the environment variable CYGWIN. - -Why do some of my old symlinks don't work anymore? - - -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. - -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. - - Why do some files, which are not executables have the 'x' type. diff --git a/winsup/doc/faq-using.xml b/winsup/doc/faq-using.xml index 9650538ba..ad6043863 100644 --- a/winsup/doc/faq-using.xml +++ b/winsup/doc/faq-using.xml @@ -367,19 +367,15 @@ formfeed character to your file. 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. +Cygwin relies on the setting of the setting of LANG/LC_xxx environment +variables. -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 +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. To type international characters (£äö) in @@ -391,23 +387,19 @@ string handling. This is planned for a later release, though. set convert-meta off set output-meta on set input-meta on - set kanji-code sjis These are options to the readline library, which you can read about in the bash(1) and readline(3) man pages. Other tools that do not use readline for display, such as less -and ls, require additional settings, which could be put -in your ~/.bashrc: +and ls, might require additional settings for doublebyte +or multibyte charsets, which could be put +in your ~/.bashrc, for instance: alias less='/bin/less -r' alias ls='/bin/ls -F --color=tty --show-control-chars' -export LANG="ja_JP.SJIS" -export OUTPUT_CHARSET="sjis" -These examples use the Japanese Shift-JIS character set, obviously -you will want to change them for your own locale. @@ -975,6 +967,24 @@ Cygwin application providing a native GUI. + +Why do some of my old symlinks don't work anymore? + + +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. + +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. + + Why don't symlinks work on samba-mounted filesystems?