Yes, I care, but I never said I wasn't just a tad nuts, too. \:D

I guess what goes on in my head when I see this is - somebody decides to create a long, complex Shell command, and then posts it here when it doesn't work. Instead of breaking it down, or even looking at the syntax before running the command, diagnosis of the command result begins. The problem is, you aren't seeing (or we aren't told) the error message.

Consider the following - we're fans of the Tom and Jerry cartoon series (Am I dating myself? Again?) We create a txt file to store our notes about an episode we just viewed by
 Code:
C:\temp>notepad tom&jerry

We might be a bit annoyed when we see the result, but it will lead us in the right direction. Notepad opens, and the file name is "tom.txt", and the command line has a message stating
 Code:
'jerry' is not recognized as an internal or external command,
operable program or batch file.

Clearly, the "&" is being interpreted by the shell. Changing the command so we wrap the "&" in quotes solves the problem.
 Code:
C:\temp>notepad "tom&jerry"
results in notepad opening Tom&Jerry.txt, as we want.

I'm still wondering why Gargoyle inserted SPACES, because if he had inserted QUOTES (which are Chr(34)) his example might have worked. Too much sun and high temps, I guess. ;\) I say "might" have worked because the position of the quotes are important, too. The string with the ampersand is a parameter to an argument - a series of arguments, actually. Placement of the quotes around one argument and its parameter might not be correct, while placement around all argument/parameters, or specific parameters might be. That's why creating this in a Bat file to test the syntax and then moving a working command to Kix is a good idea.

That's the principal behind building the command line - you can debug it in small pieces; you can display it; you can copy/paste it to run it manually; you can edit that command line when things don't work to understand why, which then makes it easy to fix your original Kix code.

Throughout 18 years of teaching coding methods, I've always said "there's no wrong way to code a solution, but there are lots of bad ways. You're here to learn the good, the bad, and the ugly" (bet you knew that was coming, didn't ya!). Long, complex command strings like this fall into the Ugly category, bordering heavily on bad.

Glenn

PS - Thanks, Richard (I think)!
_________________________
Actually I am a Rocket Scientist! \:D