[J_McQuade]

Not directly related to this new Atuin feature, but I need to vent:

Last week I was trying to `find` something in some directories, failed, `cd`d to my home directory and instinctively hit up-arrow+return to run the search again. At some time prior to this, Atuin had stopped recording new entries without my notice. Want to guess the last entry that Atuin did record?

Go on. Guess.

Yep.

`rm -rf *`

In my home directory.

Luckily I have backups of everything important and didn't actually lose anything, and I'm mainly posting this here as a funny anecdote. But - still - after getting myself set up again I have yet to reinstall Atuin.

[recursivegirth]

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

[Fnoord]

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.

[nurumaik]

"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

[63stack]

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.

[skydhash]

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.

[ianeff]

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

[citizenpaul]

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.

[rtpg]

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!

[jasonpeacock]

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

[jlengrand]

when was the last time this happened to you?

[slig]

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