I encountered some problems when using Command. Please help me solve them

fn main() {
    let result = Command::new("PlantsVsZombies.exe")
        .stdout(Stdio::null())
        .stderr(Stdio::null())
        .stdin(Stdio::null())
        .spawn();

    println!("{:?}",result);
}

I tried to compile the above file and run it on other users' computers. Errors occurred and it prompted that the file could not be found.

However, the probability of this situation is extremely low, that is, most users are normal and only a few will report errors.

But when I changed the code to the following, there were no errors. Why is this? Please answer.

fn main() {
    let result = Command::new("PlantsVsZombies.exe")
        .spawn();

    println!("{:?}",result);
}

What errors? It's impossible for us to help if you don't post the exact error messages that you encountered.

Some context would be nice too. What's PlantsVsZombies.exe, what does/should it do? Why do you think people would have it on their computer (at all, and especially at a location included in PATH)?

4 Likes

My error report content is like this:

PS C:\Users\Administrator\Desktop\植物大战僵尸杂交版v2.2压缩包版本> .\Test.exe
Err(Os { code: 2, kind: NotFound, message: "系统找不到指定的文件。" })

Why am I certain that the file exists? Because I conducted the test by remotely controlling the user's device myself. In the same environment, when I removed the following code, the operation became normal. On the contrary, this problem occurred. I'm sure it's not a problem with the path. Whether it's an absolute path or a relative path, the same content will be prompted. (The key point is that the operation is normal after removing the following code.)

.stdout(Stdio::null())
.stderr(Stdio::null())
.stdin(Stdio::null())

At present, this problem has been encountered in a small number of users' Win7 and Win10. The occurrence of this situation is relatively rare.

But I don't understand why the operation is normal after removing that part of the code. I used x86_64-pc-windows-msvc and i686-pc-windows-msvc for compilation, and the results were all the same.

could it be some anti-(virus|malware|etc.) running on target user's machine blocking app's access to target file?
(due to redirected in/out-puts in final compiled binary flagging it as a security threat?)
edit: typo

3 Likes

But after repeated attempts, I found that the following several lines of code would affect the running result, as in the comment I posted above.

.stdout(Stdio::null())
.stderr(Stdio::null())
.stdin(Stdio::null())

Have you tried some divide-and-conquer? Try each .std* call. Do all three have to be set for a failure? Or a subset?

The code of interest.

1 Like

As long as one of them exists, it will fail.

This seems the most likely.

  • It only happens when redirecting one or more
  • It only happens for some users (the ones who have antivirus block it)