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.

"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

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.