the article you mention is excellent and difficult to improve, but it is pretty technical. I will try to give a less technical explanation (bear with me, Unix guru!)
A pipe is just a unidirectional data channel: it can only be written on one end and read from the other. For bi-directional interprocess communication, you will always need two pipes. Pipes move pieces nicely, but not much more.
A pty (pseudo-terminal) can be read and written at both ends, but it is much more than just a bi-directional data channel. To understand this, it is useful to look at the real terminal: one end is a process that reads keystrokes and sends characters to teletype or screen. On the other hand, a real person appears on the keyboard looking at the aforementioned screen. Only one end has a file descriptor, the other end is only a connector and cable.
Historically, terminals have developed many attributes that can be controlled by programs running on them (for example, "echo mode" or "canonical mode", see termios (3) ). In addition, the terminal can allow the user (via the aforementioned connector and cable) to send signals that can be used for “job control”, for example by typing CTRL-Z to set the front task in the background.
A pty as a real terminal, where both ends are file descriptors:
the slave end behaves just like a real terminal: a process that has a handle for the slave end ("incomplete process") can read and write to it, as well as set terminal attributes, such as an echo mode or an interrupt character (for example, CTRL + C). Usually he does not even realize that he is not connected to the real screen and keyboard.
the main end is more like a keyboard and teletype for use, rather than people, but other processes: any process that opened the master end can write to it and receive an echo (but only if the lower process set the ECHO attribute on the slave) . It can also (in most modern devices) manage a session that has a subordinate as a control terminal), for example. by sending CTRL + Z.
To understand what a control terminal is , it is useful to think again about the scenario when a real user logs in to a real terminal. The user can start a "session", i.e. A set of processes, some in the foreground, others in the background.
To prevent chaos, the control terminal (i.e., the associated kernel structure) monitors which processes are in the front or background job and which processes are allowed to read and write to it. Whenever a process tries something illegal (for example, reading a background process from the control terminal), the operation will fail (using EIO ) and the whole task will be stopped by the kernel (using the SIGTTIN signal)
This shows that, as in the case of a real terminal, only the slave end of pty can be a control terminal, and that the concept makes sense only in a Unix system that supports job management (any Unix system currently)