Agreed backslashing embedded double quotes is the easiest way of dealing with things on the command line. However, I'd still like to get a grip on exactly how double-quotes are parsed by CMD.EXE.

One reason is that if you ever have to try and pass a filename that contains spaces to an external program via cmd.exe, especialy if it is one that won't accept forward slashes as path separators, the mess of backslashed backslashes escaping embedded quotes is just so damned messy to get right.

I'm sure that there is some logic to it, even if it is twisted logic. I think the source of the messiness related to the fact that you can quote individual parts of a complete path as well as a whole path.

P:\test>dir d:\"Program Files"\"Apache Group"\*
 Volume in drive D is Winnt
 Volume Serial Number is D822-5AE5

 Directory of d:\Program Files\Apache Group

31/05/02  17:38         <DIR>          .
31/05/02  17:38         <DIR>          ..
31/05/02  17:38         <DIR>          Apache2
               3 File(s)              0 bytes
                            947,634,176 bytes free
[download]

However, that's notth complete story as if you try and pass this into a c program like perl

P:\test>perl pq.pl8 d:\"Program Files"\"Textpad 4"\*
(d:"Program)
(Files"Textpad 4\*)
[download]

You get an almighty mess. Add an extra set of quotes and you get

P:\test>perl pq.pl8 "d:\"Program Files"\"Textpad 4"\*"
(d:"Program Files"Textpad)
(4\*)
[download]

TO achieve the desired result you have to escape the backslashes

P:\test>perl pq.pl8 d:\\"Program Files"\\"Textpad 4"\*
(d:\Program Files\Textpad 4\*)
[download]

I can't help but think that using backslash as an escape character on a system that has programs that require the backslash be used as the path separator is a terminally (sic) bad idea.

Oh well. Our's is not to reason why......