Access to the `ChildProcess` of a `sync::Terminal`

[UARTman]

Your crate currently does not expose a sync::Terminal's child_proc field in any way. Thus, it is impossible to do things like wait on a process, or get access to its underlying stderr - the only possible interaction with the child process is to close it through Terminal::close. Seeing as you're planning on using AsRef (and, presumably, AsMut) in async::Terminal to expose its inner tokio::Child (#2 (comment)), are there any blocking issues that prevent doing the same in sync::Terminal?

[michaelvanstraten]

Hi @UARTman, sorry for the delayed response.

I am somewhat unsure if I still want to go the AsRef route. I ideally don't want the ability to render the terminal into a closed state. That's the reason why the only exists a consuming close method currently. I agree that this is somewhat in contrast to what the standard library does.

What is your opinion on this?

[UARTman]

I might be misunderstanding something, but I think your concerns about rendering the terminal itself into a "closed" state might not apply here.

After I hacked the AsRef/AsMut support onto your library, I was stumped by the following behaivor:

I had a main thread that created the terminal and spawned the process, then started a worker thread, waited on the process, sent a signal that the process existed to the worker and finally waited for it to finish. The worker thread would read() the output and trying to match a password prompt with regexes basically forever, until it received the signal that the process finished and exited, returning the entire process's output.

This didn't work, precisely because the process being dead doesn't actually kill the pty pair itself - so the read() would not terminate, and the worker thread would never exit.

In the end, I switched wez's portable_pty, then found out I needed to destroy the terminals myself, which portable_pty does by implementing a Drop trait on the pseudoterminals. It was all rather counterintuitive.

When it comes to API design I am a out of my depth, but portable_pty might be something to reference, if only as an example of what not to do in some areas (they have their own Command rather than using std's and I still don't understand why).

[UARTman]

If my attempt at explaining the behavior isn't clear, let me know and I'll try reproducing the code when I have the time (I don't have it on hand unfortunately).

[michaelvanstraten]

On what platform where you when this occurred?

Regarding the use of std::command::Command it is very probable that the feature I added to the windows CommandExt trait didn't exist yet in the standard library, rendering it unusable on windows.

I don't know why the child io does not terminate the read when killing the child. But I will take a look at it.

[UARTman]

I was using Linux.