It would be really awesome if teetty would passthrough the SIGWINCH signal to the inferior pty. i.e. capture the SIGWINCH signal sent to teetty and send it to the inferior process of the teetty pty. Or perhaps this is the job of another utility to proxy signals.

Even tcl/expect does not support this, to my knowledge.

http://www.rkoucha.fr/tech_corner/sigwinch.html

Example of resizing inside and out of teetty:

https://asciinema.org/a/548055

✏️ Fix typo in README

Summary: In the example, stdout is redirected to ./stdout

Test Plan: N/A

Stack created with Sapling. Best reviewed with ReviewStack.

• -> #1

Using a FIFO for stdin often results in Resource temporarily unavailable.

On the other hand, the problem goes away when using a plain text file for --in.

mkfifo /tmp/stdin
teetty --in /tmp/stdin --out /tmp/stdout -- python
echo "import os" >> /tmp/stdin

Python 3.8.2 (default, Sep  2 2022, 20:24:00)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import os
>>> import os
>>> import os
>>> import os
>>> teetty: Resource temporarily unavailable (os error 11)

Demonstration:

https://asciinema.org/a/547789

I am using rustc 1.65.0 (Fedora 1.65.0-1.fc37)

cargo install teetty results in

error[E0432]: unresolved import `std::os::fd::AsRawFd`
 --> /home/francis/.cargo/registry/src/github.com-1ecc6299db9ec823/teetty-0.1.0/src/spawn.rs:4:5
  |
4 | use std::os::fd::AsRawFd;
  |     ^^^^^^^^^^^^^^^^^^^^ no `AsRawFd` in `os::fd`

error[E0603]: module `fd` is private
 --> /home/francis/.cargo/registry/src/github.com-1ecc6299db9ec823/teetty-0.1.0/src/spawn.rs:4:14
  |
4 | use std::os::fd::AsRawFd;
  |              ^^ private module
  |
note: the module `fd` is defined here

error[E0599]: no method named `as_raw_fd` found for reference `&&mut File` in the current scope
   --> /home/francis/.cargo/registry/src/github.com-1ecc6299db9ec823/teetty-0.1.0/src/spawn.rs:163:31
    |
163 |             read_fds.insert(f.as_raw_fd());
    |                               ^^^^^^^^^ method not found in `&&mut File`
    |
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
1   | use std::os::unix::io::AsRawFd;
    |

error[E0599]: no method named `as_raw_fd` found for mutable reference `&mut &mut File` in the current scope
   --> /home/francis/.cargo/registry/src/github.com-1ecc6299db9ec823/teetty-0.1.0/src/spawn.rs:192:36
    |
192 |             if read_fds.contains(f.as_raw_fd()) {
    |                                    ^^^^^^^^^ method not found in `&mut &mut File`
    |
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
1   | use std::os::unix::io::AsRawFd;
    |

Some errors have detailed explanations: E0432, E0599, E0603.
For more information about an error, try `rustc --explain E0432`.
error: could not compile `teetty` due to 4 previous errors

Excited to use this once I can compile! It exactly solves a problem I have been struggling to address with fd redirection in Bash alone.

At the moment ECHO is turned off which is not intended and also does not match the behavior of the screencast. The reason for this is that when ECHO is enabled there are platform differences about whether ^D also shows up. On linux apparently it doesn't and on macOS it does. I intend on turning ECHO back on out of the box (except in script mode potentially) and to figure out what to do with these differences.

The CPU core is being maxed out after sending input to teetty.

I assume it is polling the file which is responsible. It would be nice to eliminate the CPU usage using inotify.

On Linux, the GNU coreutils version of tail uses inotify to block waiting for changed to the file. With FreeBSD, tail uses kevent to do the same. This will be better than repeatedly checking for changes and sleeping.

https://asciinema.org/a/548071

The handling of stdin with multiplexed streams is a bit weird. It works in that the in file attached basically cannot really close the stream unless it sends ^D in, but it now also means that if the regular stdin closes (eg: it's connected to /dev/null) you end up with ^Dmore-input-here.

One would expect that hitting the end of the attached stdin does not necessarily send ^D in that case until the other stream also closes. However that stream today cannot close. I believe the behavior is best to be controlled with some flags.

Today stderr and stdout end up highly desynchronized if they are used in script mode. I believe that this is generally an unsolvable issue however faketty does not appear to have this issue despite it having separate streams. I believe that the fact that stderr appears as a tty there changes something in how tools print.