Does the master device appear just like a standard terminal to the driver program?

Question

From the Linux Programming Interface

The key point about a pseudoterminal is that the slave device appears just like a standard terminal. All of the operations that can be applied to a terminal device can also be applied to a pseudoterminal slave device. Some of these operations aren’t meaningful for a pseudoterminal (e.g., setting the terminal line speed or parity), but that’s okay, because the pseudoterminal slave silently ignores them.

The slave device appears just like a standard terminal to the terminal-oriented program. Moreover like a controlling terminal to the process of the terminal-orineted program.

Does the master device appear just like a standard terminal to the driver program? If yes, like a controlling terminal? If no, something like a device file or regular file but not necessarily a terminal's device file?

Thanks.

Answer 1

The master device looks like a terminal device file, complete with a line discipline that is accessible via tcgetattr()/tcsetattr()/&c. and a success result from isatty(). In fact it is the same line discipline instance as the slave device, and this is how the program on the master side transmits things such as window size changes to the programs on the slave side. It is also how the master-side program signals (an emulated) modem hangup, by setting the line speed to zero and thereby triggering the line discipline's hangup mechanism. (What the text says about line speed is thus incorrect. There is a case where line speed is meaningful.)

The difference lies in read/write I/O. What is read is the sequence of characters that would, for a real terminal, be sent over an actual underlying serial device. What is written is the sequence of characters that, for a real terminal, be received by that actual underlying serial device. In other words: it is the other side of canonical/non-canonical input and output processing by the line discipline.

There are complexities to this, namely packet mode and remote mode. The latter has fallen into desuetude long since, and did not exist in most operating systems even at the start of this century, necessitating patches to Daniel J. Bernstein's old pty tools. The former is not really particularly useful for most tasks, and thus I am not going to cover it in detail in this answer.

The master device is generally not the controlling terminal for the sessions in which master-side processes run. This would be conceptually putting things that are analogues to the internals of a real terminal in the wrong place. The controlling terminal for such sessions is, if it is there at all, another terminal.

This will be the case for programs such as script, NeoVIM's :terminal, emacs, and ptybandage (if not part of a pipeline), which are directly rendering to another terminal device and run within an interactive session controlled by that terminal device.

It isn't the case for an SSH server, GUI terminal emulators, console-terminal-emulator from the nosh toolset, ptyrun (in normal usage), or monolithic framebuffer terminal emulators such as zhcon. Those are rendering to all sorts of different I/O devices, from buffers and FIFOs in the filesystem in the case of console-terminal-emulator through TCP sockets to framebuffer and HID class devices, none of which are terminals. Moreover, console-terminal-emulator, SSH servers, and framebuffer terminal emulators are generally invoked in dæmon contexts where of course there is no controlling terminal for the session to begin with.

Note that the diagram is not definitive. It is not necessarily the case that the master-side process forks the slave-side processes. In nosh-toolset user-space virtual terminals, for example, the slave-side processes are ordinary ttylogin@* services, forked by the service manager, and there is no direct process relationship between the emulator process on the master side and the login session processes on the slave side. But that is going beyond the scope of this answer.

Further reading

• https://unix.stackexchange.com/a/177209/5132
• https://unix.stackexchange.com/a/249801/5132
• Jonathan de Boyne Pollard (2018). "user-space virtual terminals". nosh Guide. 1.38. nosh. JdeBP's Softwares.
• Jonathan de Boyne Pollard (2018). A quick look at user-space virtual terminals nosh. JdeBP's Softwares.

Answer 2

The master device looks mostly like a pipe. You can read and write its file descriptor like a pipe, in sizes that are convenient for you. You will get short reads, so always check what read(2) returns.