1
1
mirror of https://github.com/wez/wezterm.git synced 2024-11-24 07:46:59 +03:00
wezterm/pty/examples
Wez Furlong 53febb14ff pty: fixup for macos
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.
2022-08-12 08:37:20 -07:00
..
whoami_async.rs pty: try_clone_writer -> take_writer 2022-08-12 07:56:46 -07:00
whoami.rs pty: fixup for macos 2022-08-12 08:37:20 -07:00