If you fire up a terminal and call an executable (assuming one that's line oriented for simplicity) you get a reply to the command from the executable. How does this get printed to you (the user)? Does the terminal do something like pexpect? (poll waiting for output) or what? How does it get notified of output to be printed out? And how does a terminal start a program? (Is it something akin to python's os.fork()? ) I'm puzzled how a terminal works, I've been playing with some terminal emulator and I still don't get how all this magic works. I'm looking at the source of konsole (kde) and yakuake (possibly uses konsole) an I can't get where all that magic happens.


2 Answers 2


When you “open a terminal”, you're starting a terminal emulator program, such as xterm, gnome-terminal, lxterm, konsole, …

One of the first things the terminal emulator does is to allocate a pseudo terminal (often called a pseudo-tty, or pty for short). The pty is a pair of character device files: the pty master, which is the side that the terminal emulator opens, and the pty slave, which is the side that programs running inside the terminal have open. On most modern unices, the master is /dev/ptmx (which every terminal emulator has open) and the slave is /dev/pts/NUMBER. The kernel driver for pseudo-terminals keep track of which process controls the master for each slave device. The terminal emulator can retrieve the path to the corresponding slave through an ioctl on the master device.

Once the terminal emulator has opened the master device, it starts a subprocess (typically a shell, but it's up to the user who invoked the terminal emulator to decide). The emulator does this in the usual way to invoke a program:

  • fork a child process,
  • open the slave pty device on file descriptors 0, 1 and 2 (standard input, standard output and error stream),
  • execute the shell or other program in the child process.

When the child (or any other process) writes to the pty slave, the emulator sees input on the pty master.

Conversely, when the emulator writes to the master device, it is seen as input on the slave.

Expect works in exactly the same way. The difference between Expect and a terminal emulator such as xterm is where they get the input that they feed the program (script vs keyboard input) and what they do with the output (log file or parser vs drawing text in a window).

  • One of the simple examples of what is described here is BusyBox's implementation of the script command, where xgetpty function is the core of the work with /dev/ptmx.
    – Ruslan
    Commented Jul 1, 2017 at 6:29
  • @Tim I appreciate that English is not your native language. But if you edit a post, then please make sure that you don't make it wrong. If you don't understand it, don't edit. Also, once again, please do not use bold to highlight things that don't need highlighting. Commented Aug 9, 2017 at 19:52
  • So, basically, a terminal emulator is a program that creates a window and launches a shell. It communicates with the shell (and subprocesses) via a pseudoterminal master/slave pair (renders output to the window, and provides input). The slave is at /dev/pts/N, the master doesn't have a file (in the sense that every time you open /dev/ptmx you get a new descriptor). If we broaden the scope a little, there are also virtual consoles, implemented in the kernel. This time there's only a "slave" (/dev/ttyN, N >= 1)...
    – x-yuri
    Commented Dec 31, 2021 at 11:26
  • .../dev/tty0 points to the active virtual console, /dev/tty points to the terminal associated with the current process, be it /dev/ttyN (N >= 1), or /dev/pts/N. In a way there's some sort of xterm connected to the /dev/ttyN (N >= 1) devices in the kernel...
    – x-yuri
    Commented Dec 31, 2021 at 11:26
  • ...And there's also /dev/console which generally points to /dev/tty0, but that can be changed. Which probably dates back to the days where an administrator had a separate console (a system console). These days it's supposedly used by the kernel during boot and in single-user mode. At least that is my understanding.
    – x-yuri
    Commented Dec 31, 2021 at 11:27

Originally you had just dumb terminals - at first actually teletypewriters (similar to an electric typewriter, but with a roll of paper) (hence /dev/tty - TeleTYpers), but later screen+keyboard-combos - which just sent a key-code to the computer and the computer sent back a command that wrote the letter on the terminal (i.e. the terminal was without local echo, the computer had to order the terminal to write what the user typed on the terminal) - this is one of the reason why so many important Unix-commands are so short. Most terminals were connected by serial-lines, but (at least) one was directly connected to the computer (often the same room) - this was the console. Only a select few users were trusted to work on "the console" (this was often the only "terminal" available in single-user mode).

Later there also were some graphical terminals (so-called "xterminals", not to be confused with the xterm-program) with screen & graphical screen-card, keyboard, mouse and a simple processor; which could just run an X-server. They did not do any computations themselves, so the X-clients ran on the computer they were connected to. Some had hard disks, but they could also boot over the network. They were popular in the early 1990s, before PCs became so cheap and powerful.

Later still, there were "smart" or "intelligent" terminals. Smart terminals have the ability to process user input (line-editing at the shell prompt like inserting characters, removing words with Ctrl-W, removing letters with Ctrl-H or Backspace) without help from the computer. The earlier dumb terminals, on the other hand, could not perform such onsite line-editing. On a dumb terminal, when the user presses a key, the terminal sends/delegates the resulting key-code to the computer to handle. After handling it, the computer sends the result back to the dumb terminal to display (e.g. pressing Ctrl-W would send a key-code to the computer, the computer would interpret that to mean "delete the last word", so the computer would handle that text change, then simply give the dumb terminal the output it should display).

A "terminal emulator" – the "terminal-window" you open with programs such as xterm or konsole – tries to mimic the functionality of such smarter terminals. Also programs such as PuTTY (Windows) emulate these smart terminal emulators.

With the PC, where "the console" (keyboard+screen) and "the computer" is more of a single unit, you got "virtual terminals" (on Linux, keys Alt+F1 through Alt+F6) instead, but these too mimic old-style terminals. Of course, with Unix/Linux becoming more of a desktop operating system often used by a single user, you now do most of your work "at the console", where users before used terminals connected by serial-lines.

It's of course the shell that starts programs. And it uses the fork system-call (C language) to make a copy of itself with a environment-settings, then the exec system-call is used to turn this copy into the command you wanted to run. The shell suspends (unless the command is run in the background) until the command completes. As the command inherits the settings for stdin, stdout and stderr from the shell, the command will write to the terminal's screen and receive input from the terminal's keyboard.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .