Hi Igor,
Igor Pechtchanski <[EMAIL PROTECTED]> writes: > This is probably an ASCII vs Unicode issue. Most of Cygwin calls > the ASCII versions of the Windows API. I'm not sure Cygwin is even > Unicode-aware. Windows uses Unicode internally to encode the > filenames. It's probably that some program is writing scripts in the standard GUI 8-bit encoding (so-called "ANSI"). But program parameters are read in the console encoding (so-called "OEM") and than Windows re-encodes them as Unicode and from there to "ANSI" to pass to the actual process. The actual console encoding can be set on NT based systems (and only there) through APIs and the command utility CHCP.COM. Their handling by Cygwin also depends on the CYGWIN environment variable. For background just a short reminder of the Windows encoding mess: Windows has Unicode and 8-bit versions of all APIs that take string values. Most of the Unicode versions only work on NT and it's descendents, on Windows 9x/Me the Unicode APIs are present but most just return an error. The 8-bit versions use different encodings for different locales. They are called "ANSI", because they were based on ANSI/ISO standard encodings when they were first introduced. Windows consoles do not use those "ANSI" encodings, but another set called "OEM" encodings, these were inherited from DOS. Both "ANSI" and "IBM" encodings are identified by their number in IBM's codepage registry. Western Windows versions use 1252 for Windows APIs and 850 in the console. > Theoretically, Windows should do the right translation under the > covers. It may be as simple as setting the correct codepage or > locale before trying to create the path... You can't change the encoding on Windows 9x/Me (at least not easily and not on a vanilla system). On NT you can use CHCP.COM. benny
