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)

@b0rk I really wish we could have structured data across pipes just so we could get highlighting back at the end of pipe-based tool chaining. Lumin is nice enough, but thin gruel in comparison.
@mhoye @b0rk this is one of the few things I really like about Powershell.
@petrillic @mhoye @b0rk nushell also does structured data, and is cross-platform
@itamarst @mhoye @b0rk oooo will check it out. I hate the general syntax of Powershell but the structured data aspect is a huge win.

@petrillic @itamarst @b0rk

I’m convinced that if powershell had been born anywhere but Microsoft it would have replaced bash entirely by now. Even structured data is thin gruel compared to pipelines passing structures objects.

@itamarst @petrillic @mhoye @b0rk

https://www.nushell.sh to save someone else some clicks. I’m definitely going to take a look at this.

I’m not sure if I found the right lumin? https://lumin.readthedocs.io/en/stable/

Nushell

A new type of shell.