Regarding how it deals with relative paths, it seems that the spawned process assumes a position in the file system relative to where the parent process was spawned, not where the child process was spawned.
You cannot use the same opened file in multiple commands because they take ownership of the file descriptor and close it once the command finishes.
If you capture stderr to print it later but the command fails with a non-zero status code, it will drop the stderr and return an empty enum. Stdout and stderr are only returned if the command terminates correctly.
There is no way to convert duct::Cmd to a std::process::Command that is needed to deal with process group IDs.
That's why I am moving to xshell. However, it does not handle async, so the addition of Tokio is required. Moving everything to Tokio raises all the problems related to issue #228. I handled them using the approach that @pepyakin and I came up with. Zombie processes should not be a problem anymore
Duct exhibits too many peculiar behaviors:
duct::Cmd
to astd::process::Command
that is needed to deal with process group IDs.That's why I am moving to
xshell.
However, it does not handle async, so the addition of Tokio is required. Moving everything to Tokio raises all the problems related to issue #228. I handled them using the approach that @pepyakin and I came up with. Zombie processes should not be a problem anymorecloses #228