cygpath 2.6.0: -m " C:" and garbled output

cygpath 2.6.0: -m " C:" and garbled output

[Andre Maroneze]

I just noticed a difference in behavior between versions 2.5.2 and
2.6.0 of cygpath (the ones I could test): if I run

cygpath -m " C:"

(notice the space before the C, inside the double quotes)

In cygpath 2.6.0, this outputs C? (C followed by the unicode character
0xF03A, which is a ":" (0x3A) character, but prefixed with "F0").
In cygpath 2.5.2 (and 2.4.1, which I also could test), it outputs C:,
as I would expect.

This happens on both Windows 7 and Windows 8.1, and not only on my
machine, so it seems fairly deterministic.

Is it some sort of undefined behavior to give an argument to cygpath
starting with a space inside double quotes?

Otherwise, is this an intended change to 2.6.0?

Regards,
Andre

--
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

Re: cygpath 2.6.0: -m " C:" and garbled output

[Ken Brown]

On 10/6/2016 8:38 AM, Andre Maroneze wrote:
> I just noticed a difference in behavior between versions 2.5.2 and
> 2.6.0 of cygpath (the ones I could test): if I run
>
> cygpath -m " C:"
>
> (notice the space before the C, inside the double quotes)
>
> In cygpath 2.6.0, this outputs C? (C followed by the unicode character
> 0xF03A, which is a ":" (0x3A) character, but prefixed with "F0").
> In cygpath 2.5.2 (and 2.4.1, which I also could test), it outputs C:,
> as I would expect.
>
> This happens on both Windows 7 and Windows 8.1, and not only on my
> machine, so it seems fairly deterministic.
>
> Is it some sort of undefined behavior to give an argument to cygpath
> starting with a space inside double quotes?

I think you'll find the explanation here:

https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars

I don't know why this doesn't happen with earlier versions of cygwin.

Ken

--
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

Re: cygpath 2.6.0: -m " C:" and garbled output

[Achim Gratz]

Andre Maroneze writes:
> I just noticed a difference in behavior between versions 2.5.2 and
> 2.6.0 of cygpath (the ones I could test): if I run
>
> cygpath -m " C:"
>
> (notice the space before the C, inside the double quotes)

A filename can legitimately start with a space and it is a relative
filename in that case.  So dropping the space just to get something that
looks like a drive letter is wrong.

> In cygpath 2.6.0, this outputs C? (C followed by the unicode character
> 0xF03A, which is a ":" (0x3A) character, but prefixed with "F0").

That's how the otherwise forbidden ":" character gets encoded into the
filename.

> In cygpath 2.5.2 (and 2.4.1, which I also could test), it outputs C:,
> as I would expect.

No, that's wrong as explained above.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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

Re: cygpath 2.6.0: -m " C:" and garbled output

[Andre Maroneze]

Just to clarify, " C:" is not the entire filepath I was giving to
cygpath, it's more like " C:/Temp/a.txt", but I reduced to it when
trying to isolate the difference between versions.

On Thu, Oct 6, 2016 at 9:26 PM, Achim Gratz <Stromeko@nexgo.de> wrote:
> A filename can legitimately start with a space and it is a relative filename in that case.  So dropping the space just to get something that looks like a drive letter is wrong.

Indeed! I hadn't thought it that way, and it nicely explains why no
conversion happens without the space (in which case it would be
considered an absolute file path, despite starting with "C:").

> That's how the otherwise forbidden ":" character gets encoded into the filename.

I do know that ":" is forbidden in a filename, but because I (assumed
I) was giving it a file path (and one which was supposed to be
absolute), I didn't consider that the rules about special filenames
would apply. But having a relative file path changes everything.

>> In cygpath 2.5.2 (and 2.4.1, which I also could test), it outputs C:, as I would expect.
>
> No, that's wrong as explained above.

I should have said, "as I got used to expect due to past behavior". I
would guess those versions were more lenient towards absolute file
paths, which would however be an issue for filenames starting with
spaces.

Thanks to both of you for the clarifications. In the end, the extra
whitespace was incorrectly inserted by a makefile function call, so I
fixed it anyway, but I wanted to fully understand the issue to avoid
incurring into similar problems later.

--
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