On Tue, 5 Mar 2002, Roth, Kevin P. wrote:

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

Yeah, there's been nothing new in that neighbourhood recently.

> 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

The URL is wrongly formatted. The syntax should be

 file://[host]/[path]

Where [host] is always ignored by curl and widely never used, so thus most
commonly just empty:

 file:///[path]

Thus the above should've been

 $ curl file:///c:\\temp\\test.txt

curl contains some weird code that attemps to work-around this syntax error
though.

> 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?).

Yes, normally in unix that part is taken care of by the shell.

I checked the code and I just can't understand how this happens. There's only
one part of the entire curl code that should deal with backslashes at all,
and that's the code that does the / to \ conversion for file:// to construct
a fully windows-looking path name from the URL input.

Also, when I try this out on unix, I get outputs like this:

$ curl "moo\\\\\\"
curl: (6) Couldn't resolve host 'moo\\\'

Which shows that after the shell has converted each pair of backslashes into
single ones, curl doesn't seem to mock with them. The similar goes for
file:// of course:

$ curl "file:///moo\\\\\\"
curl: (37) Couldn't open file /moo\\\

> Will the fix likely be a cygwin-specific patch, or can it somehow be a more
> general purpose patch?

At this moment this tastes like a cygwin chew.

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

Fire up gdb. Set a break-point in main(). type 'run [url]'

Does the argv[1] contain the properly looking string? If so, then the problem
is within curl.

Step into operate() and down a dozen lines or so until getparameter() is
called for each command line argument. For the URL itself (line 1995) it
calls the getparameter() and should end up at mainc:1067 where it appends the
URL to a linked list of URLs to get.

On main.c:2044 starts the loop that loops through all given URLs, step with
the code for a while and see the URL get picked out from a struct,
de-globbified and then passed to libcurl. Where does the problem start?

If you get this far, I bet you have some further data we can work on... :-)

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/