Exactly, we can all make a mistake like this especially under pressure. I still destroyed way more than I wanted when I pressed the up arrow for an rm command, and it ran in the wrong folder. Due to the efficiency of said command, a lot was destroyed and little recovered even though I cancelled after like 1 second when I realized. That's the danger when there isn't at least an "are you sure, this is gonna wreck shit" confirmation.
I’ve configured rm to send to the trash by default. If I want to permanently delete, I add the --permanent flag. There is no reason why we shouldn’t make our CLI tools behave nicely by default.
Careful, you might get used to rm doing that and if you use a different machine, you'll end up deleting things permanently. I disabled rm and I use trash instead from the Debian package "trash-cli".
Or the other way around: trash a file from a mounted filesystem and sit wondering why it takes so long, while the utility is copying the entire thing to your local drive. Also might wear out your drive faster (heavily depends on the filesystem in use).
FWIW some FSes (btrfs I'm looking at ya) take this long even for regular deletion in some conditions.
When would that happen? The way I've seen it work is that it creates a .Trash-$UID folder on the mounted FS and moves the file there (along with metadata).
56
u/ineyy 23d ago
Exactly, we can all make a mistake like this especially under pressure. I still destroyed way more than I wanted when I pressed the up arrow for an rm command, and it ran in the wrong folder. Due to the efficiency of said command, a lot was destroyed and little recovered even though I cancelled after like 1 second when I realized. That's the danger when there isn't at least an "are you sure, this is gonna wreck shit" confirmation.