Let the ELF Note Everything

Being Santa is a quite busy occupation, especially in December. Therefore, he is eager to delegate as many chores as possible to his hardworking ELFs. For this, he shows the respective ELFs how the task is done once and the ELF has to scribble down everything step-by-step. Nevertheless, even in this tutorial for the intended work flow, Santa is so fast that even the fastest ELF cannot handle to write everything down in time. Can you help the ELFs to build something that automatically notes all the commands Santa issues during the tutorial session?

Pseudo Terminals

Unix was developed in a time, where computer terminals like the VT05 where the new and shiny gadgets that replaced the teletype writer (hence tty). In short tele-typewriters where typewriters connected to the telephone system. For an early Unix user, it was quite normal to log into the machine via telephone on his typewriter, where his strokes where send via telephone to the machine, where it was fed as standard input to the remote process. The process wrote something on its stdout, which was send via the telephone line to the teletypewriter, which printed the output. This setup also explains why the ed(1) editor is line-oriented; vi, with its visual editing features, made only sense after computer terminals evolved. Despite this short historic digression, we learn that (1) interactive processes on Unix speak to (teletype or computer) terminals and (2) the connection is bi-directional.

Probably, you do not have a real computer terminal in hardware at home, but still you are using abstractions that are based on this idea of the teletypewriter: the pseudo teletypewriters (pty(7)), which is another inter-process primitive of Unix systems. In contrast to pipes, which are only uni-directional, a pty is a pair of bi-directional file descriptors. This means that every end can write and read on its end of the pty. Furthermore, to make the illusion of teletypes even more perfect, both ends are not equal, but there is a primary and a secondary end, and we can manipulate the behavior (echo input, flow control) only at the primary end.

For your terminal emulator (e.g. xterm(1)), the emulator creates a new pty pair and gives the secondary fd to a new shell process as stdin, stdout, and stderr. Afterwards, xterm reads the outputs from the primary fd and displays it in its graphical window. Keystrokes are then written to the primary fd. Also, xterm implements flow control: With Ctrl-s you can stop the output and resume it again with Ctrl-q. If you list the directory /proc/self/fd, you get a glimpse on the file-descriptor setup of an interactive process:

We see here, that the file descriptors 0-2 all point to the secondary pseudo terminal file /dev/pts/3. Please also note that the ls-process, whose open file descriptors we see here, has the directory /proc/1471637/fd opened to read out the directory listing with getdents().

Task

Build the scribble program that acts as a proxy for another program's standard input and output. Everything the user types into stdin, scribble sends to its child process's stdin but also notes it in a separate file. Similar, scribble also dumps everything it receives from the child to another file before writing it to its stdout. All in all, scribble is very similar to the tool script(1), but much simpler.

An example session could look like this:

For this session, the STDIN file would then contain:

and the STDOUT file:

Please note, that 1+1 and 2+2 appear twice, since the terminal echoes the typed-in commands.

Hints

• Use two copy-and-dump threads, one for each direction (terminal to stdin, stdout to terminal) instead of trying to do everything in a non-blocking, epoll()-like fashion.
• Use O_NOCTTY, when opening /dev/ptmx.
• When having the primary end of the pty in your hand, use TIOCGPTN to deduce the pseudo-terminal number. Also, you have to unlock the primary fd, before using it (TIOCSPTLCK).

Last modified: 2023-12-01 15:52:28.055739, Last author: , Permalink: /p/advent-15-pty