Notices by Julia Evans (b0rk@social.jvns.ca)

I think a lot about how information about how computers work often seems to get passed down in an "oral history" kind of way

like how “the terminal” works is sort of documented, but it's made of so many components that the documentation is split across a million different documents

and some parts of "how the terminal works" are just broad conventions which aren't documented anywhere I know of (like “TUI programs like `top` or `less` will probably quit if you press `q`)

slowly working on a mega terminal cheat sheet

here's a link to the draft as a PDF: https://jvns.ca/terminal-cheat-sheet-draft.pdf

canonical mode

the terminal: cast of characters

got a lot of great answers to "how is the shell involved in handling Ctrl+C" to the effect of one of:

- "the shell is responsible for sending a SIGINT"
- "the shell takes input from the terminal emulator and relays it to the program"
- "it must be handled by the layer above the program, which is the shell"

and while none of those is true, they feel like they totally _could_ be true in a different world. It feels hard to explain why it might be useful to have a more "accurate" mental model

follow up: for folks who replied to "who's in charge of making Ctrl+C work in the terminal" with "the shell”, why did you say that?

I'm much more interested in answers that you're not 100% sure about than "right" answers

(also please don't correct people who say something you think is "wrong”)

(2/?)

@anthk do you ever do that in practice?

one thing I've learned about teaching over the years is that if I make a negative statement (like “git commits aren't stored as diffs"), it doesn't really work -- often people will just ignore it, especially if it contradicts their current mental model

so I always have to figure out how to make a positive statement, and make it in a way that will convince people whose mental model is different right now

convincing people to adjust their mental models is really hard!

we've been looking into shipping zines to Europe from an the EU instead of from the US and I think it might be possible! Still need to figure out all the details (and it still might not work out for various reasons) but fingers crossed.

@wollman oh interesting, I thought the point of the line editing stuff was to make it faster (and do it locally on the terminal) but I guess that's not true!

I've been thinking about the "terminal driver" and I realized I'm kind of confused it. my understanding is that the terminal driver is responsible for (among others):

1. basic line editing (when the tty is in cooked mode)
2. translating bytes (like `\x03` for Ctrl+C) into signals (like SIGINT)

but in the 1980s when the "terminal" and the "mainframe" were separate machines, #1 would presumably happen on the terminal, and #2 on the mainframe

but now they're both handled in the same place?

just got this new “Love Your Bugs" sticker in the mail! Anyone who buys a print copy of “The Pocket Guide to Debugging" will get this free sticker with it

https://wizardzines.com/zines/debugging-guide/

(you can also get just the sticker here if you want https://store.wizardzines.com/products/love-your-bugs-sticker)

i tried nix for the first time 2 years ago and I've given up on using it as a package manager locally (I just went back to homebrew), but I'm still using NixOS. Even though it's very confusing it still feels like the easiest way for me to manage a server

I remembered from this thread that I use nix not because I really like it but because configuring servers without a declarative system always stresses me out and I guess right now I'm willing to give up a lot of nice things I like (like "being able to understand error messages”) to get a declarative config system

(usually I get a "declarative system" by using something like github pages or fly.io but for a VPS it's nix)

it's a bit funny to me that having a declarative way to configure my servers feels so important to me, I think it's because I touch my servers pretty rarely and so if the way I manage them isn't declarative then I just get more and more and more scared of what is happening there over time.

and also I have zero self discipline so if I use ansible I will always at some point just SSH into the machine and start changing random stuff without putting it into ansible. With Nix I can't do that.

I think one reason I often feel a bit conflicted about writing about Nix is that even though I use it myself, it's only because my choice to use it doesn't impact anyone but me

I've had too many experiences where someone on a team chose to use a "difficult" piece of software (like bazel) despite huge usability issues because it had some perceived benefit and didn't acknowledge the impact that can have on other people who have to use the software

standards for ANSI escape codes https://jvns.ca/blog/2025/03/07/escape-code-standards/

I'm curious about what a "reasonably common supported set of ANSI escape codes” might be but I'm having a hard time finding a document that lays it out

I see the word “vt100" a lot but when I read about the vt100 in for example https://vt100.net/docs/vt100-ug/chapter3.html#S3.3 there's also some stuff that doesn't seem relevant to modern terminal emulators like "Load the four programmable LEDs..."

or there's ECMA-48 but is everything in there actually still used?

or there's the xterm sequences but that seems too big?

exciting news: almost 300 of the comics at https://wizardzines.com/comics/ now have transcripts! (more than 60%!) Also you can use the search to search the transcripts

shell history

(with a shoutout to https://atuin.sh)