Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If you fire up a terminal and call an executable (assuming one thats 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.

share|improve this question
Take a look at a simple terminal emulator and a simple toy operating system with a simple shell (and the first fifteen or so pages of its book). Also, read this answer to a related question. – Evan Teitelman Jun 13 '13 at 21:58
nice thanks for the link – mike Jun 14 '13 at 12:12
This link is also intersting to the terminal subject and tty history: linusakesson.net/programming/tty/index.php – nwildner Jun 14 '13 at 13:54
@nwildner cool, – mike Jun 14 '13 at 14:35
up vote 23 down vote accepted

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 computer 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 harddisks, but they could also boot over the network. They were popular in the early 1990s, before PCs became so cheap and powerful.

A "terminal emulator" - the "terminal-window" you open with programs like xterm or konsole - tries to mimic the functionality of such dumb terminals. Also programs like PuTTY (Windows) emulate terminals.

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 singe 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-systemcall (C language) to make a copy of itself with a environment-settings, then the exec-systemcall 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.

share|improve this answer
And in between the dumb serial terminals and Xterms there was en.wikipedia.org/wiki/Blit_(computer_terminal) – sendmoreinfo Jun 16 '13 at 19:37

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). It does this in the usual way to invoke a program: fork a child process, and execute the shell or other program in the child process. Before executing the program, the emulator opens the slave pty device on file descriptors 0, 1 and 2 (standard input, standard output and error stream).

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).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.