I'd love ideas for how to intentionally "break" my terminal so that one of these 4 things happen:

1. backspace doesn’t work, it prints ^H instead
2. terminal won't echo my characters when you type them
3. the line not breaking, and the terminal pasting new characters over old ones
4. overflowing the line, and when I backspace, the line is poorly redrawn

ideally I'd love steps that are:

a) specific
b) might (more or less) "realistically” happen while using the terminal normally
c) not Ctrl-S

@b0rk If this means you will eventually write a "how to stop your terminal from doing any of these 4 things" guide I will jump for joy

@b0rk for 2 (well most of them really but this one is 'easiest' ime), that can happen when you have a tui that exits without resetting the terminal, i'm not at a keyboard right now but i'd try `kill -9`ing things like htop or vim

@passcod thanks! I tried kill -9ing htop and nvim and neither of those caused any problems sadly

thanks for all the suggestions for how to break my terminal, here are the ones that have worked for me so far:

1. start a less capable shell (like dash), then `cat /usr/bin/vim` (screenshot included)
2. start `screen` and then `kill -9` it. Breaks my terminal in a way that can't be fixed with `reset`.
3. start `htop` in bash/zsh and then `kill -9` it. Causes using the mouse to print control characters. (doesn't break in fish though)
4. killing almost any TUI app in bash/zsh seems to break it

@b0rk Several of these things can happen "realistically" if a full-screen terminal application (less, vim, mc, ...) crashes in a way that prevents it from putting the terminal back in its original mode on the way out. You can simulate such a crash by `kill -9`-ing one of these apps from another terminal.

Note that current generation shells may mask the issue because their editable command prompts also involve messing with the terminal mode.

*Which* of the breakages you get depends on what the app did to the terminal, I will be more specific later today when I have a real keyboard to type on.

@zwol ah yeah I've been trying that but haven't been able to get my terminal to break by doing it!

@b0rk you can run screen and then `kill -9` both the `SCREEN` and the `screen` process. This will leave your terminal in raw state with the behavior you describe. It could realistically happen if your screen was killed by some rogue program or by accident. While your terminal driver will be in raw mode, all modern shells do their own line editing and you'll not be as screwed as you might hope (but exiting from `cat` will be a challenge). HTH.

@hanshuebner thanks, that worked! (and typing `reset` doesn't fix it either)

@b0rk What about adding a number 5:

5. cat-ting a binary file to stdout/err accidentally and causing the terminal to just render garbage from there on out (so badly that "stty sane" and similar can't even fix it — the problem manifested almost like video corruption whereby characters would become remapped to new ones)

This was a pretty significant problem in the past. It's harder to make happen today (hardening), but fixing it has always been indeterminate short of restarting terminal/reboot.

@matt I also remember it being a problem in the past but can't figure out how to reproduce it at all today

@b0rk oh, also, and an accident that happens to me every so often, cat a binary file to the screen. not inherently dangerous, but it tends to hit funky escape codes and screw things up on average

@b0rk oh you've just said that. you know, your shell might be too good and reset things when it gets control back. does it work in simpler 'sh'? maybe a busybox sh?

@passcod yesss that works (in `dash` on my machine), it's so beautiful

@b0rk cating a binary file will have random effects, completely dependent on what's in the file.

Killing a TUI program will again have random effects, depending on how it configured the terminal – while killing htop doesn't really break the terminal, it does leave mouse input enabled, so clicking or wheeling inside the terminal window will cause garbage to be typed.

@jernej__s what shell are you using? when I `kill -9` htop it does not cause mouse issues like that

@b0rk bash shell, pterm (putty)

Does your htop respond to mouse? If it doesn't, you won't see this problem. Try running mc -x (this forces Midnight Commander to run in "xterm" mode, which enables mouse), then killall -9 mc, which should leave mouse input enabled.

@jernej__s it does! `kill -9`ing htop causes the problem you describe if I do it from bash/zsh, just not from fish (my usual shell)

I think what I'm learning from these answers is that the reason I was having trouble breaking my terminal is that my shell (fish) is much more resistant to breaking the terminal than bash/zsh are, so a lot of the normal "broken terminal" things haven't happened to me in a long time

Not sure exactly what fish is doing to avoid getting "broken" by various terminal problems but it's cool

@b0rk interrupting password entry with ctrl-c or ctrl-\ frequently leaves the terminal in a no-echo mode so you can't see what you are typing

The reset command usually fixes most terminal issues, but you might need to type ctrl-m instead of return for it to take

@RandomDamage huh interesting, I can only really reproduce this problem in `dash`, bash/zsh/fish all seem pretty resistant to it.

do you know what shell you've run into this in?

@b0rk https://github.com/fish-shell/fish-shell/issues/4873 might be most of it

@pc thanks!

@b0rk I used to get it in bash, we've got a utility ptogram at work that sometimes triggers this due to a called program but I haven't figured out exactly how that's happening to be able to reproduce it yet

@RandomDamage thanks!

@b0rk If I might suggest a fifth fun one:
echo -e '\016'
enables the funky line graphics character mode, and even `reset; stty sane` doesn't fix it, so I have a `stty-saner` alias that also does
echo -e '\017'
to turn the damn thing off.

Typically hit this accidentally if you get binary files output to the terminal.

@neko what shell are you using? I tried it in a few different shells but it didn't seem to have any effect

@b0rk GNU bash, version 5.2.15, Konsole, on Debian if it matters.

@neko also what does it look like? I'm not sure what I should be looking for exactly

@b0rk In case you haven’t seen this, Build Your Own Text Editor taught me a lot about what’s going on under the hood in a terminal, although it really only scratches the surface. But I think if you wanted to induce some of these behaviors programmatically (not sure if that’s desired or not), the first couple sections might be interesting to look at?

@b0rk It looks like you have a lot of good responses already so I tried to dive right into the deep end and figure out what kill -9'ing screen does that reset can't fix but i couldn't make it happen for me despite using bash so it's probably something specific to macos or your terminal emulator (i've got alacritty)

also just _trying_ to find docs for terminal control sequences has given me a headache :-(

regretfully, me

@zwol it might be a mac os thing! I've given up on trying to figure it out for now (I made this asciinema video of me trying to type echo "hello there” over and over again and failing https://asciinema.org/a/WNa8ffluzeqLb3Jo9NGzXOXej but I don't know what to make of it, all I can say is that I am definitely typing the same thing each time)

@b0rk never in 30 years of unixing have I seen anything like that

I wonder what you'd get if you attached the equivalent of strace (macos has *something* like strace, right??) to fish right after the kill and logged exactly what it is reading and writing and if that might shed some light

@zwol the strace situation on mac os is really dire sadly