When compiling "things" under cygwin, it's possible to have an executable (such as less.exe) that will recognize posix paths (e.g. /home/kevin/tmp.txt) and windows paths (e.g. C:\cygwin\home\kevin\tmp.txt) somewhat interchangably. In addition, they can properly follow the shell symantics, with regard to backslashes. In other words, when refering to a windows path under bash, I have to double up the back-slashes (e.g. C:\\cygwin\\home...), while under the cmd.exe windows command shell, this is not necessary.

I tried this under curl 7.9.5 pre6 (probably similar under previous versions), and I see the following:

 from cygwin's bash prompt:

 $ curl file:///c/temp/test.txt works ok (posix path)

 $ curl file://c:\\temp\\test.txt NOT ok (escaped dos path)
 curl: (37) Couldn't open file c:temptest.txt

 $ curl file://c:\\\\temp\\\\test.txt works ok (double-escaped dos path)

 $ curl 'file://c:\temp\test.txt' NOT ok (quoted dos path)
 curl: (37) Couldn't open file c:temptest.txt

 $ curl 'file://c:\\temp\\test.txt' works ok (quoted AND escaped dos path)

 from dos prompt:

> curl file:///c/temp/test.txt works fine (posix path)

> curl file://c:\temp\test.txt fails, but would have
               expected this to work fine from a dos shell
 curl: (37) Couldn't open file c:temptest.txt

> curl file://c:\\temp\\test.txt works fine (extra quotes)

> curl file://c:/temp/test.txt (not really a valid path
               representation, a mix of posix forward
               slashes and dos drive letter, however less.exe
               handles this one fine, so I though maybe we should)
 curl: (37) Couldn't open file /temp/test.txt

It appears that somewhere inside its command line parsing, curl.exe is losing a set of back-slashes. Wondering whether this is needed (doesn't a typical unix shell do this before passing along to the application?). Will the fix likely be a cygwin-specific patch, or can it somehow be a more general purpose patch?

If it needs to be cygwin specific, I'll make an attempt at it, if I can figure out where to look. Any pointers would be appreciated.

--Kevin
Received on 2002-03-05