I want to execute a program in my Rust app on Windows, I want the program to keep running after my app exit and show outputs, I have tried this but not work, a new console will open but no outputs shown on that
let mut cmd = Command::new(program);
Your spawn will die when the program ends. You may want to fork() your new process.
No it won't.
From the docs for
There is no implementation of
Drop for child processes, so if you do not ensure the
Child has exited then it will continue to run, even after the
Child handle to the child process has gone out of scope.
I suspect what is happening is that the OP is starting their program by double-clicking their EXE which will create a console window that stays open until that program exits. The child process is still alive, but the console it was writing output to no longer exists.
If you want to continue seeing output after the parent process completes, make sure you start the parent executable from an existing console window.
The parent app has enabled
windows_subsystem = "windows" , is it related to this setting, I have also tried to start the child program by using
cmd.exe /c child.exe but still get a blank console
Rust unconditionally sets the
STARTF_USESTDHANDLES flag (source) and passes the parent (or pipe or null) stdout/stderr handles to the child causing output to be redirected there. Unfortunately it seems like you cannot override that using the std library. I suggest opening an issue on the Rust repo requesting to make that behavior configurable.
Oh, thanks. I probably should not give advice as I am so beginner. I thought Command::spawn worked like thread::spawn and returned a join handle but I see now the sentence "Executes the command as a child process, returning a handle to it." the "handle" is not a JoinHandle.
It's great for beginners to give advice here, that way everyone learns more!
I couldn't agree more!
Sometimes it also helps when you aren't an expert in something. Say someone has a problem where they need to use
unsafe (e.g. they want to call a function from the Windows API) and aren't quite sure how to pass a byte buffer as an argument... Someone who has been living and breathing
unsafe code for years will tend to give a complex response and get so focused on handling subtle edge cases (plus all the "well, actually" responses that come with it) that they don't properly answer the question in a way the OP can understand. On the other hand, someone who's played around with the Windows API a bit and knows just enough to be dangerous might give the straightforward solution the OP is looking for.
I'm exaggerating, but the curse of knowledge is a very real thing.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.