Re: cygpath behaviour when input is not a path

[Andy Koppe <andy dot koppe at gmail dot com>]

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