Sat Feb 25 16:38:00 GMT 2017
On 2/21/2017 1:22 PM, Nellis, Kenneth (Conduent) wrote:
> From: Andrey Repin
>>> But, consider the following:
>>> $ cygpath -w a:b | od -An -tx1c
>>> 41 3a 62 0a
>>> A : b \n
>>> Instead of the special character colon (:), shouldn't cygpath be showing
>>> something in the Unicode Private Use area?
>> No, it shouldn't.
>> You've requested a name "b" in the current directory on the disk "A:", or
>> a file substream "b" of the file "a".
>> Both are valid system paths.
> Right. Thanx. I wondered why the "a" got up-cased.
> I suppose one could argue that, by using -w, that cygpath might assume that it
> is converting *from* a POSIX path, and therefore the colon would not indicate
> a drive letter--wouldn't that make sense?--but Iâll let someone else take up
> that battle. âº
I would almost agree except for the help description of the -w option.
Also a : isn't a valid character for a name in Windows. Cygwin uses
some magic to represent it in UNICODE format though.
> Also, in the following, I would expect cygpath to figure out that I *am not*
> specifying a drive letter:
> $ cygpath -w ./a:b | od -An -tx1c
> 41 3a 62 0a
> A : b \n
Consider the following as what should happen with "./a:b" but the
current result of "a:b" could already be considered correct. With the
following I think the output give fro "./a:b" is incorrect. Not
withstanding the argument for relational output of the windows path.
$ cygpath -w ../a:b | od -An -tx1c
43 3a 5c 6f 70 74 5c 63 79 67 77 69 6e 36 34 5c
C : \ o p t \ c y g w i n 6 4 \
68 6f 6d 65 5c 61 ef 80 ba 62 0a
h o m e \ a 357 200 272 b \n
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin