As the other answers said, yes, it's because terminals were originally connected to serial ports.
If you have 2 computers with functioning serial ports, at least one of them running a unix-like OS, and a null modem cable to connect them, you can still do this now. On one end, configure ttyS0
as a login port (by editing /etc/inittab
or some similar file where the getty
commands are), and on the other end run a terminal emulator that knows how to drive a serial port (e.g. minicom, screen, putty). For bonus points, run cu
or tip
on an existing terminal instead.
If you can't conduct this experiment, you can still observe other remaining effects of the historical close relationship between tty's and serial ports, by looking at all the options available in the stty
command. Several of them (speed, parity, number of data bits and stop bits, "local" mode, handling of break signals...) are serial port settings that make no sense on any other kind of tty. But they exist on every tty because historically there was no dividing line between configuring the serial port itself and configuring the driver to understand the terminal on the other end of the serial line, so everything was shoved into the stty
tool.
You can run stty -a
on any tty that isn't a real serial port, and if you match up all the listed modes to their description in man stty
, you'll probably find that it is set to 38400 baud, 8 data bits, no parity, 1 stop bit. These settings are pointless. Attempts to change them will either be rejected or have no effect. On ttyS0
, you have to get those settings right or the terminal won't work at all.
Then there's the ^S
and ^Q
special characters to stop and restart terminal output. They still work, but they're not very helpful unless the terminal is a fairly slow serial device. Mostly ^S
just provides a way for people to accidentally freeze their terminals and get confused.