On 29 May 2010 16:20, Gary wrote: > I wrote: >> How should cygcheck > > cygpath, not cygcheck > > /me smacks head > >> behave when given a "PATH list" (e.g., >> '/bin:/usr/bin'), *without* the -p option? >> >> For example: >> $ cygpath -a -p -C ANSI -w /bin:/usr/bin >> C:\cygwin\bin;C:\cygwin\bin >> >> = okay. What I expect from RTFMP. >> >> $ cygpath -a -C ANSI -w /bin:/usr/bin >> C:\cygwin\bin?\usr\bin >> >> Urk! I would have hoped it wouldn't try to convert this, or at the very >> least not the last part, but I don't know if it's a bug, "by design", or >> what.
A colon is a valid character in a POSIX filename, i.e. the path your converting there starts with a directory called 'bin:'. Colons aren't allowed in Windows filenames though, which is why Cygwin maps it to the Unicode private use area: U+F03A. Without the '-C ANSI' option, and assuming you're using a UTF-8 locale, that would be displayed as the "Unicode replacement character", usually an empty box or a question mark in a box, depending on the font. But with the '-C ANSI' option, the string is converted to your ANSI codepage, presumably CP1252, whereby codepoints such as U+F03A that can't be represented in that codepage are turned into question mark characters. Have you got any particular reason for overriding the locale charset with the -C option? Doing that will probably cause breakage with any filenames containing non-ASCII characters. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple