But it's a convenient least-common-denominator and abstraction layer for text-mode applications. We might not be using physical teletypewriters now (or VT100-s

But it's a convenient least-common-denominator and abstraction layer for text-mode applications. We might not be using physical teletypewriters now (or VT100-style video terminals), but it's really convenient to be able to write an application once and know that it's going to just work whether I'm running it in a text-mode console or in xterm or in gnome-terminal or over ssh or in tmux within any of those or... Sure, we could come up with some other standard, but the TTY interface is one we already have, with a huge amount of code already written to work with it; why fix what isn't broken? Contrast this with Windows; until recently, command-line applications there were pretty tightly coupled to the console host that they ran within [1]; this made remoting of command-line applications difficult and means you had to go through extraordinary hoops just to do things like replace the system's console UI with something like ConEmu or run a terminal within something like Visual Studio Code. More recent versions of Windows try to improve this situation, by adding support for Unix-style pseudoterminals [2] (what they call ConPTY) to the console subsystem. And since ConPTY terminals are based around the same standards as TTY terminals on *nix, things like OpenSSH remoting can now "just work", even for existing command line apps on Windows. [1] See here for some of the gory details of how this works and how it differs from the conventional *nix approach: https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/ https://devblogs.microsoft.com/commandline/windows-command-l... [2] Blog post describing the PTY infrastructure on Windows: https://devblogs.microsoft.com/commandline/windows-command-line-introducing-the-windows-pseudo-console-conpty/ https://devblogs.microsoft.com/commandline/windows-command-l...