7 ms·

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 di

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.

jasonpeacock 1y ago
I mean, the same thing would happen if Bash stopped writing to `~/.bash_history` and its last item was `rm`, right?
- jlengrand 1y ago
  when was the last time this happened to you?
recursivegirth 1y ago
Destructive options shouldn't be allowed to be run from history without confirmation. That seems like a reasonable fix to this issue.
- nurumaik 1y ago
  "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
  - stingraycharles 1y ago
    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.
- Fnoord 1y ago
  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/imnyang/tsh https://github.com/Byron/trash-rs 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.
- 63stack 1y ago
  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.
slig 1y ago
I believe zsh asks for a confirmation before doing that. Which shell are you using?
skydhash 1y ago
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 1y ago
  That’s right, man. Bury me with my zshrc.
rtpg 1y ago
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!
citizenpaul 1y ago
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.

jasonpeacock 1y ago

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

jlengrand 1y ago
when was the last time this happened to you?

recursivegirth 1y ago

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

nurumaik 1y ago
"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
- stingraycharles 1y ago
  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.
Fnoord 1y ago
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/imnyang/tsh https://github.com/Byron/trash-rs 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.
63stack 1y ago
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.

slig 1y ago

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

skydhash 1y ago

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 1y ago
That’s right, man. Bury me with my zshrc.

rtpg 1y ago

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!

citizenpaul 1y ago

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.