I'm working with pseudoterminals (unix) and pseudoconsoles (windows). The spawning process is fairly involved (unix needs things like setsid, custom stdio, set controlling tty, etc., windows needs custom CreateProcess call to attach pseudoconsole). For this reason, using std::process::Command is out of the question (currently feasible on Unix, impossible on Windows) for the purpose of having a uniform API.
However, once the process is spawned, all of the operations supported by std::process::Child are possible (and desired), like try_wait(), kill(), id(), ...
However, it is not currently possible to create a Child struct from a RawHandle (windows) or Pid/u32 (unix). As a result, we're reimplementing most of Child in our library. It's not a huge amount of code, but it's a little unfortunate that it's necessary at all.
I understand that constructing from raw OS handles/file descriptors is quite fickle, but Command/Child is the only OS abstraction that does not currently allow this
It wouldn't reacquire the IO handles, but it looks like it should just be a matter of adding an implementation; the only fields of Child are the IO handles (public options, so could be provided after construction if you have them) and a process handle (private).
@LunarLambda I think getting this implemented in std::process::Child should not be too difficult.
I have looked at a reference implementation of ConPTY, and it starts the Child Process just like the windows/process.rs std implementation, given some minor adjustments to the lpStartupInfo as well as setting bInheritHandles to false.
Theoretically we could add a new method to the std::process::Command struct to which a Pseudoterminal could be passed. Internally the Pseudoterminal would hold the handle to the master, slave descriptors/handles which would replace the descriptors/handles of stdin, stdout, sterr and the created process.
I would be willing to implement this if someone could tell me if this is mergeable into the standard library.