17 comments

[ 5.1 ms ] story [ 47.8 ms ] thread
This moves files to the actual OS system trash/recycle bin: https://www.npmjs.com/package/trash-cli

- Working great on MacOS!

- For some reason the latest versions occasionally didn't work on Windows 11. (I forgot the actual reason...)

I aliased rm=trash and RM=rm so I could still access the real rm when needed.

I don't think aliasing rm is a good idea because you might get used to rm=safe and cause a problem on an ssh server where this utility isn't installed
For some rarely use server, this could be the case. However, any frequently used servers that will always be some base configuration via ansible, dotfiles etc. that can add the base alias to the shell.
Technical comments: I don’t think Unix style should mix multiple purposes into one executable. I would keep save, restore, and list functions as separate executables.

I hope it was fun.

In case you were wondering, this is at least four decades late on the invention front.

Thanks for your feedback. Let me think through the interface a bit more.
trash-cli has existed for a while, although it may not work on MacOS. A feature comparison might be useful.
Similar, rm-safely is just a simple shell function though. you don't need to really install another specialty command, just copy over rm() function put them in your shell rc.
Rip2 is another useful alternative: https://github.com/MilesCranmer/rip2

I have a small wrapper around rip2, aliased to `recycle`; files go to a `graveyard` zfs dataset. I deny `rm` usage for agents, a simple (global) instruction pointing to recycle seems to do the trick for Claude.

Seems like a quick win to remove some downside risk and make me a bit more comfortable letting agents run wild in local workspaces.

At least for me, over 90% of unintentional file deletions (not counting ill-considered deletions) are due to mv and cp rather than rm. Being careless with them can easily end up overwriting a file's contents with another. For instance, once I was typing out a few commands of form "cp foo.txt bar.txt baz/", but I inadvertently hit Enter before writing "baz/", causing bar.txt to get overwritten with foo.txt. I don't know of any good solution for this issue, apart from my current rule of thumb never to use more than two arguments at a time.

   $ > important-file-1.txt

   $ cp crap.txt important-file-2.txt

   $ ln -sf blah important-file-3.txt

   $ mv crap.txt important-file-4.txt

Now what?

Editor backups, git, real backups.

My main fear with things like this is that using it will get me into a pattern of thinking I'm safe, so that then when I'm doing something on another system that doesn't have this, I'll accidentally make a mistake and won't be able to undo it. This is a fundamental problem with nearly all attempts to make things easier or safer. A lot of what makes things safe or unsafe has to do with our level of attention to what we're doing; conveniences that allow us to reduce our attention can paradoxically make things less safe unless they're baked in at the very lowest level.
Great point. Actually rm -i should be baked in our workflow so we can be a little bit more aware.
For the opposite there is "wipe" command but I'm not sure if it works on SSD too or only on classic magnetic disks.
You throw away stderr a few times: "2>/dev/null"; at worst this could hide real problems, at best it's not very helpful to the user.
I muchly prefer btrfs snapshots with snapper. Protects against all kinds of mistakes, not only rm.