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.
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.
I don't know exactly what's the logic but sometimes I need to confirm a rm operation with an "y". Maybe cp and mv should have the same behavior for destructive operations.
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.
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.
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.
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.
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.
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.
If you're using the GNU implementations; --no-clobber, --backup or --update. Can be aliased too.
I don't know exactly what's the logic but sometimes I need to confirm a rm operation with an "y". Maybe cp and mv should have the same behavior for destructive operations.
> I don't know exactly what's the logic but sometimes I need to confirm a rm operation with an "y".
I believe some Linux distributions alias rm to either rm -i or -I in their default shell config.
trash-cli has existed for a while, although it may not work on MacOS. A feature comparison might be useful.
There is indeed a similar, maybe even same, trash that works on MacOS and available on brew. Users are covered there too.
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.
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
Good point~
I use fish shell abbreviations, now.
`rm` expands into `trash` so I know it's been "aliased."
I don't ssh into servers often, but hopefully I'd notice `rm` didn't expand.
--
On a similar note, I used to alias `cd` to zoxide. But now I just use the default `j` to avoid confusion with `cd`
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.
Many apps already exist in this category.
They usually also follow XDG, and some are cross os.
I’m currently using https://github.com/Byron/trash-rs
Supports windows, macOS and Linux.
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.
For the opposite there is "wipe" command but I'm not sure if it works on SSD too or only on classic magnetic disks.
I muchly prefer btrfs snapshots with snapper. Protects against all kinds of mistakes, not only rm.
Editor backups, git, real backups.
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.
I just run stuff in seatbelt sandbox, it seems decent.
[dead]
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.