This is great! I’ve been remotely logging into systems for all of my adult life and last week I went on a bender because I realized didn’t really grasp how these things actually work.
I am not sure I do now (specifically how SSH ties in to this).
But at least I now know more about terminals, shells, rawmode and ptms/ptx and more.
This link right here fits right in with the following ones:
I am not sure I do now (specifically how SSH ties in to this).
SSH isn’t that complicated (well, the terminal bits, at least). The PTY layer is a client-server interface. When you create a PTY, you get two file descriptors. The client looks like a terminal, the server has a bunch of ioctls for receiving the out-of-band commands that the client sends.
The ssh daemon each creates one of these pairs. The daemon hands the client to the shell (or other command that it invokes[1]) and hangs onto the other. Anything that it receives on the server, it sends over the network connection. On the client side, it simply forwards these commands to its own TTY.
[1] By default, running other commands doesn’t create a new PTY, but it can if you pass the right flag. Otherwise you get a pipe.
It skips over one stage: punch cards came after (and were more expensive than) paper tape and were the earliest form that allowed some not-totally-horrible editing experience. If you made a mistake in a program on paper tape, you needed to either retype the whole thing (and make a different mistake) or cit the tape and attempt to splice a replacement back in. With punch cards, you could copy the correct bits of a card onto a new one and replace it in the middle of the deck.
As a result, not many OSes give us the chance to interact with virtual consoles nowadays; but Linux-based systems still have them.
This is somewhat misleading. I believe virtual terminals predated Linux. They’re also present on *BSD. The layering was somewhat unfortunate on many of the implementations. I think this is fixed in Linux now, but for a long time they worked only on architectures that had a text mode display: you didn’t get virtual terminals on SPARC, for example, where the console was a framebuffer.
If you access a remote server (or an embedded device) without any graphical interface, you’ll only have the virtual console to work with; better knowing how it works in these cases!
If it doesn’t have a display, it won’t work with virtual terminals. You’ll need a serial terminal of a pseudoterminal tunnelled over the network for this.
This is great! I’ve been remotely logging into systems for all of my adult life and last week I went on a bender because I realized didn’t really grasp how these things actually work.
I am not sure I do now (specifically how SSH ties in to this).
But at least I now know more about terminals, shells, rawmode and ptms/ptx and more.
This link right here fits right in with the following ones:
[0] https://biriukov.dev/docs/fd-pipe-session-terminal/4-terminals-and-pseudoterminals/
[1] https://www.sobyte.net/post/2022-05/tty/
[2] http://www.linusakesson.net/programming/tty/index.php
SSH isn’t that complicated (well, the terminal bits, at least). The PTY layer is a client-server interface. When you create a PTY, you get two file descriptors. The client looks like a terminal, the server has a bunch of
ioctls for receiving the out-of-band commands that the client sends.The ssh daemon each creates one of these pairs. The daemon hands the client to the shell (or other command that it invokes[1]) and hangs onto the other. Anything that it receives on the server, it sends over the network connection. On the client side, it simply forwards these commands to its own TTY.
[1] By default, running other commands doesn’t create a new PTY, but it can if you pass the right flag. Otherwise you get a pipe.
Great article. A few minor pedantic points:
It skips over one stage: punch cards came after (and were more expensive than) paper tape and were the earliest form that allowed some not-totally-horrible editing experience. If you made a mistake in a program on paper tape, you needed to either retype the whole thing (and make a different mistake) or cit the tape and attempt to splice a replacement back in. With punch cards, you could copy the correct bits of a card onto a new one and replace it in the middle of the deck.
This is somewhat misleading. I believe virtual terminals predated Linux. They’re also present on *BSD. The layering was somewhat unfortunate on many of the implementations. I think this is fixed in Linux now, but for a long time they worked only on architectures that had a text mode display: you didn’t get virtual terminals on SPARC, for example, where the console was a framebuffer.
If it doesn’t have a display, it won’t work with virtual terminals. You’ll need a serial terminal of a pseudoterminal tunnelled over the network for this.