For those seeing "Expect" and not knowing what's going on: https://en.wikipedia.org/wiki/Expect

One of Tcl's first "killer apps". Don Libes' (creator of Expect) book "Exploring Expect" is also one of those technical masterpieces that are very enjoyable, entertaining technical reads. Recommended if only for the discussions of terminals and interactive i/o.

[edit: typo/punctuation]

This is a bit of a tangent, but one issue with the POSIX (and underlying BSD/Linux) APIs is that they don't act nicely with mount namespacing (and thus containers). Since every /dev/pts mountpoint has a different set of ptys associated with it, you need to join a mount namespace in order to operate on /dev/pts/... (and the only way to get a slavefd is to open /dev/pts/$num).

This is of particular concern to container runtimes, so I recently wrote a patch that added a new tty_ioctl(4)[1] to make things _slightly_ better (though I think the pty namespacing concept really needs to be reworked -- not to mention the countless lovely problems with Linux's namespace primitives). Effectively it allows you to safely open a slavefd given a masterfd (without needing to worry about mount namespace issues).

Short story, if you're an author of a container runtime I would take a look at using that feature.

[1]: https://marc.info/?l=linux-kernel&m=149649933504954&w=2

Controlling a human-interactive program with another program is pounding a screw, but it does work for simple programs.

...or the interaction challenges that will give rise to significant advances in AI.

in case not want to install tcl

https://github.com/drudru/pty4

http://empty.sourceforge.net

The problems that are solved by PTYs finally "clicked" for me when I read their example of the problematic fseek/flushing. I hadn't seen such a cogent expiation until now.

True, but be warned, that fseek is not a real example. You cannot fseek/lseek on character devices. You would have to use a different technique.

Expect?

Yes.[0]

[0]: https://en.m.wikipedia.org/wiki/Expect