On Wed, 6 Mar 2002, Roth, Kevin P. wrote:

> Here's the short version - after realizing gdb wasn't so hard to use after
> all

Hehe! I'm glad I could trick you into world of gdb. :-)

> I realized that the function urlglob.c:glob_word() was causing the grief I
> noticed (wherein I have to use an extra set of backslashes, even from the
> windows cmd.exe shell and the win32 native version of curl.exe).

This is such a nice catch, Kevin. You not only made gdb work for you, you
found and solved this very neatly! A big *thanks* from me!

> Here's a patch that corrects the problem, if you'd care to accept it:

[snip]

The patch is fine. I did however not apply it exactly like that, as I thought
it over and couldn't come up with a reason for making that check conditional
for windows-only. I think it should apply for all platforms.

> On this topic, I'm curious - if I tried something like
> file://other_machine_name//home/kevin/test.txt, what network protocol would
> be used to access that other machine?

That is not stated in the RFC, which also makes this totally useless. IE uses
SMB (I think), other browsers tend to ignore the host part. Like curl does.

> To me (although I realize this topic has been
> hashed out previously on this list), it should be:
> file://[path-spec]
> where "file://" is the URI prefix, similar to http://, ftp://, etc..., and
> "[path-spec]" would be the path to the requested file, in whatever syntax
> is valid for the current machine, which should be handled by the local
> machine.

RFC1738 (http://curl.haxx.se/rfc/rfc1738.txt) section 3.10 says:
<quote>
   A file URL takes the form:

       file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.
</quote>

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