every so often I get confused because I'm writing a zine about the terminal and didn't I already write 4 zines about the terminal???

but I've never written about what the UI “rules” you need to know to use the terminal interactively are, only:

- notes on core Unix concepts — file descriptors, signals, etc (Bite Size Linux)
- shell scripting (Bite Size Bash)
- cheat sheets for sed/grep/xargs/etc (Bite Size Command Line)
- cheat sheets for command line networking tools (Bite Size Networking)

I haven't totally sold myself yet on this "what are the secret rules of the terminal?” framing but it feels like a reasonable way to talk about how, even though “the terminal” is a lot of separate things working together, it "feels" like a cohesive environment that has a lot of rules that you can generally expect to be true.

Some of those rules are Unchangeable Facts and some of them are just Vague Social Rules but understanding the vague social rules is just as important as knowing The Facts.

an example of a "social rule" in the terminal is that if you have a noninteractive program, you can generally expect that `Ctrl-C` will stop it, programs can do whatever they want but it would just be kind of rude for a noninteractive program to not respect `Ctrl-C`

(there are different and more complicated social expectations around how to quit interactive programs)

another example of a "social rule" is that at an interactive prompt you should expect `Ctrl-W` to delete the last word, this is weird because depending on the _kind_ of program, the exact mechanism for how `Ctrl-W` will delete the last word might change, but I think it would be generally considered rude if a program with an interactive prompt treated `Ctrl-W` in a different way

(text editors are an exception though and generally are allowed to handle text editing however they please)

another social rule is that if a program is writing its stdout to a file or pipe, it's expected to turn off colour codes so that users don't end up looking at output like this:

ESC[1;33massets.jsESC[0m

(as far as I know there is almost nothing enforcing this behaviour except that users will be unhappy if you don't do it)

another funny example of a "social rule" in the terminal is that it's not actually considered THAT rude for a program to not support arrow keys, like if the program only takes very limited interactive input (like just `y`/`n` or entering a number), then it's normal for the arrow keys to not work. Git is an example of this.
@b0rk I don't know if it is a social rule, but rather common behavior enforced by the TTY driver that the terminal program uses. Or, rather, that the kernel runs whenever somebody reads from a terminal.
@rsalz @b0rk nope, the tty doesn't do anything with such escape sequences. The following stackexchange explains it quite well: https://unix.stackexchange.com/a/103764
Is there any reason why I get ^[[A when I press up arrow at the console login screen?

Whenever I'm at the console login, I press up arrow intentionally to see the previously typed commands. But I see this ^[[A. But when I press Ctrl Alt Print Screen Scroll Lock Pause Break Page Up ...

Unix & Linux Stack Exchange
@sam @b0rk it does some of the things like ctrlC ctrlW delete etc
@rsalz @sam can you leave me out of this conversation thanks
@rsalz Ok yeah I get it. And the kernel eats ctrl+alt+delete/shift+alt+FX/...