e6421d1b72 removed this bit from the
example:
```
-
- // Note that we're waiting until after we've read the output
- // to call `wait` on the process.
- // On macOS Catalina, waiting on the process seems to prevent
- // its output from making it into the pty.
- println!("child status: {:?}", child.wait().unwrap());
```
This commit revisits that and puts in place a differently horrible
solution for macos.
The issue is that if we don't put in a short sleep on macos, then
for a short lived process like `whoami` in this example, we end up
reading output like this:
```
; cargo run --example whoami
Compiling portable-pty v0.8.0 (/Users/wez/wez-personal/wezterm/pty)
Finished dev [unoptimized + debuginfo] target(s) in 0.60s
Running `/Users/wez/wez-personal/wezterm/target/debug/examples/whoami`
child status: ExitStatus { code: 0, signal: None }
output: \r\n^D\u{8}\u{8}wez\r\n%
```
where the EOT that we send on Drop somehow gets *prepended* to the output
that we read from the pty with a couple of BELs thrown in.
I'm not sure WTF is happening on macOS for that to occur; feels like
some kind of race wrt. process startup and initializing the pty in the
system.
The reader has to be started before we close it as well, otherwise
the same issue can occur.
This breaking API change allows us to explicitly generate EOF when the
taken writer is dropped.
The examples have been updated to show how to manage read, write
and waiting without deadlock for both linux and windows.
Need to confirm that this is still good on macOS, but my
confidence is high.
I've also removed ssh2 support from this crate as part of this
change. We haven't used it directly in wezterm in a long while
and removing it from here means that there is slightly less code
to keep compiling over and over.
refs: https://github.com/wez/wezterm/discussions/2392
refs: https://github.com/wez/wezterm/issues/1396
Seems that you need to have read everything you want before you
call waitpid, otherwise the pending data seems to be snipped and
prevented from being read.
closes: https://github.com/wez/wezterm/issues/187
It's too fiddly to setup in practice, and literally no one has
expressed an interest in using it.
Removing it simplifies some upcoming work.
Closes: https://github.com/wez/wezterm/issues/35
