I am running the following code on windows. It is passing a command that requires quotes around one of the parameters: "00100010=lastname^(first name)^" when I run the command directly on the command line it works fine, when running it by rust it fails saying
storescu: 00100010 lastname(first name)
It appears to be removing the = and ^ I can't seem to get it working no matter what I try.
I can replicate the error on the command line by removing the = sign but it still shows the ^ eg:
storescu: 00100010 lastname^(first name)^
let mut test_output = Command::new("storescu.bat")
.stdout(Stdio::piped())
.arg("-b")
.arg("aet")
.args( &["-s", "\"00100010=lastname^(first name)^\""])
.spawn()
.expect("storescu command failed to start");
The Windows command-line has a bunch of legacy "quirks", like how wildcards (e.g. dir *.txt) don't actually get expanded and it's left up to every command to implement their own glob expansion.
In your case, it looks like cmd.exe does something funky when interpreting the arguments passed to a batch script.
The ^ character is used for escaping in cmd.exe. I'm guessing when you run the command from the command-line (cmd.exe) it'll silently double the ^ symbols when formulating the command to be given to CreateProcess(). On the other side, when the batch script is executed I'm guessing cmd.exe will interpret escapes to resolve the ^^ from the command-line into a single ^.
Rust and Powershell don't play these shenanigans so the arguments you write are the arguments sent to the new process. So when the arguments came from Rust (i.e. without the doubled ^) it'll see you've tried to "escape" an open paren (e.g. "^(") and will silently remove the ^.
Parsing of ^ in DOS command-line args is magical. The command line is parsed twice, and the first pass removes most of the ^ characters by design. It's not a Rust thing, it's legacy Windows/MS-DOS thing: