I’m now running openbsd on my laptop, and I’ve yet to enable history save to file. And to date, I’ve not missed it. Anything that should be saved across sessions can be an alias, a function, a script, or a snippet in some notes.

That’s right, man. Bury me with my zshrc.

Destructive options shouldn't be allowed to be run from history without confirmation. That seems like a reasonable fix to this issue.

"Destructiveness" property is undecidable in general. If you ban rm from history, you'll just get false sense of security before you accidentally run some "aws bla bla drop production cluster"

Behavior of any system should be just one of: 1. Fully determinate 2. Have enough latency before confirmation (for example, block input for 1 second after displaying a command)

This should apply to history, any fuzzy searching, autocomplete etc

Technically it’s possible to run each command in some restricted cgroup for example, and ask for elevated permissions if anything more is required. But that would require quite some rethinking on how the whole shell is supposed to work.

A shell history has no knowledge about what the commands do.

You could also make a mistake by executing command #101 instead of #102.

1) This is why you never type rm -rf * but the absolute path.

2) Furthermore, the command flag -f implies never prompt (taken from a recent GNU coreutils man page):

"-f, --force ignore nonexistent files and arguments, never prompt"

3) This is merely unlinking; the data is still there, not overwritten.

4) You should have backups of your homedir. A filesystem with versioning like ZFS could be of help here, too.

5) Agree with you and add a blacklist to the history, with rm being a primary contender.

6) Instead of rm, use a system where you move files into a trash bin (ie. abstract the unlinking in a user-friendly interface such as the trash bin or recycle bin concept). Examples: https://github.com/imnyang/tsh https://github.com/Byron/trash-rs

Now, I think you could do #5 or #6 (and add `mv` and `dd` as well, but where does the list end?), but I think #1 (using the absolute path) is the easiest to avoid the worst PEBCAK.

No it is not a reasonable fix to this issue. You can't classify a command whether it's destructive or not. It depends on a lot of context. The classification logic needs to run every time you invoke a command. It needs to gather all the context to make a decision, every time you run a command. It's going to slow everything down. People will have different opinions on what is destructive, leading to endless debates. We don't need to run logic just to recall a history entry. Stop.

I mean, the same thing would happen if Bash stopped writing to `~/.bash_history` and its last item was `rm`, right?

when was the last time this happened to you?

I believe zsh asks for a confirmation before doing that. Which shell are you using?

the age-old trick for some of this is when running something you don't want in history, put a bunch of spaces before it.

It requires you to think about that when doing it ... but, well... I dunno. I really don't ever write `rm -rf *` even in that state of mind. That's like the most evil command one can type into a machine! Who knows what it will do!

Since atuin is a feature enhanced shell history replacement maybe you should look into its features that you could have used to prevent this. Like not allowing destructive commands with wildcards in memory.