▲ 93 points
back
18 comments
Anatomy of a Terminal Emulator - https://news.ycombinator.com/item?id=29080561 - Nov 2021 (70 comments)
> The new process [ls -l] gets the desired data, sends it to the shell and terminates.
> The shell sends the data to the terminal through the STDOUT side of the pty
Unless redirected, ls inherits the pty file descriptor from the shell¹ when the shell forks it. But after that, it's writing to the terminal emulator directly, not to the shell; that is, the shell doesn't forward `ls -l`'s output to the terminal.
¹(or really, the child inherits whatever file descriptor the shell has for stdin, stdout, stderr for its stdin, stdout, stderr, respectively, unless, for each of those, there is a redirection specified, in which case the shell replaces the file descriptor in the child as specified by the command give to the shell. stdin/stdout/stderr might be a pty in the shell, or they might not be.)
True, and thanks for pointing this out. But this example is there to illustrate the basic relationship of shell<->terminal-emulator without going in to too much details that might confuse those readers for whom it is intended.
It's kind of incredible that after ~20 years of programming I'd never come across anything illuminating this breakdown:
> The terminal emulator is a graphical application whose role it is to interpret data coming from the shell and display it on screen. This display is often textual but not always.
> The shell provides an interface to the operating system, allowing the user to interact with its file-system, run processes and often have access to basic scripting capabilities.
> These two programs are connected together by the pty (pseudoterminal) which provides a bi-directional asynchronous communication channel between the two.
Did you have a formal cs education? This was covered in my operating systems class- we had to write a basic shell as an assignment.
Yep, I did, though I didn't take an OS class. What's significant about the article (imo) is in pedagogy. I've never been particularly interested in OS implementation details or shell programming, but just because it's around I have some level of curiosity and have wondered something roughly like, "why doesn't anyone ever just say what a shell/terminal is?"—basically I was looking exactly for a concise architectural breakdown like the author gave, just as a brief answer to a quick question, and hadn't come across it until now.
Interesting, it was a required class in my program. Writing a shell is definitely a useful exercise, you may want to give it a go. We focused more on signal handling and forking/exec'ing processes though and less on display features, though from what I recall there was some raw/canonical mode stuff we had to deal with.
In my program we could do either compilers, OSes, or networks. That does sound like a fun project though—if I wanted to learn more in the area, building a toy shell is definitely the direction I'd go.
An excellent article in his "Further Reading" section:
Interesting I didn't know that terminal sessions were files. So if I was root on a shared host, I could theoretically hijack and listen to what other people are doing in their SSH sessions.
Yes, but if you're root, you could also peer into the terminal emulator's memory space itself, and see that, too. Or into their sshd process, and pull the plaintext out of that. You're root.
You might also find the man pages wall(1) and write(1) (That's the terminal utility write, not the syscall write(2).) interesting.
(Edit: well, actually, if you're SSH'd into a remote host, your terminal emulator is probably local, so you might not be able to see into its memory unless you're root locally, ofc.)
By definition as root you can, irrespective of if they are files or not. You have complete access to the memory, networking, and code execution state of the machine.
Wow, high quality blog post.
I was surprised by the assumption of ANSI and no mention of $TERM.
Fair point, but this post was mostly to tell how things are today. And these days most (all?) terminals the reader will interact with would be ANSI.
Cool domain.
The .dev TLD is owned by Google.
I feel this is the only article distinguishing this place from CNN at the moment.