Some comments have already covered the subcommands thing, but why are you using the XDG_CONFIG_HOME directory `~/.config/wrm` to store files? This should be for _configuration_ not _state_. You should follow the specification for XDG base directories for this [1] which would suggest you put the trash in `~/.local/share/wrm/trash`
This is a problem worth tackling. It's too easy to remove stuff inadvertently without easy ways to recover.
I scanned your README, here are my hot takes:
- rm is still far simpler to use, and so will be used by virtue of laziness and habits instead of your tool. You want to fight back and come up with a solution against this very hard.
- delete vs remove is going to be a nightmare. Which one is for going to trash, and which one is to irremediably removing the file? I don't know why English even has the two words, and each tool uses one or the other without a clear pattern (though English is not my first language). Maybe "wrm trash" should trash the file, and "wrm remove" should remove them irremediably, like rm ("remove") does. "delete" could be an alias of "remove".
- irremediably removing the file should be harder to do and trashing them. So maybe "trash" should be the default behavior. If no option is given to "wrm", that's what will happen. "wrm" is still longer than "rm", but that's way less annoying than typing "wrm remove"
Maybe the answer is an alias, or even (god forbid) a shadowing of the rm command in interactive shell sessions, but you might be get hatred for this because people might not like this, at least if it's done without them agreeing. There could be a setup phase that invites people to setup the shadowing in their shell rc file.
There's no absolute truth. Sub commands are neat, options have less chance to clash with existing filenames but are more annoying to write. In any case you can handle `--` to stop the parameters and begin to handle anything that follows as filenames.
If you guide the user to setup nice aliases, this should not matter too much.
I get that writing a small utility is fun, but if it is just that (for fun), I suggest you put that into the readme. Otherwise, why should I choose your tool over something like https://github.com/andreafrancia/trash-cli, which seems to already be distributed for the major distros? Does your implementation scratch an itch that the myriad of other implementations don't? I'm just curious.
I think you need some info in your readme about what this tool is and why you’d want to use it instead of “rm”.
When you say “remove files safely” is this as in “you can easily recover the file if you delete something by accident”, or “safely” as in “the file is securely erased and no one will ever be able to recover the file again after you give away this hard drive to someone else”?
I still use Rip (Rm Improved) even though it hasn't updated in 4 years https://github.com/nivekuil/rip . But a tool this simple doesn't need to. You just delete things by using 'rip thing', which I find amusing.
Looking good as far as I can see. I have two suggestions:
- explain how the tool works and how it compares to similar tools in the readme
- add completions for commands and flags. This is a must for many reasons.
edit: I will second jraph's comment about the different commands being a nightmare, I just didn't wanna say it for an alpha release. Ideally wrm would work similar to rm where `wrm foo` moves foo to trash and operations on the trash are the ones behind an extra command.
What happens when you trash ('remove') files on a different partition than your $HOME?
It sounds like if you tried to use this to remove, say some movies from a NAS, you could end up both thrashing your network and filling up your /home (or root) partition. (And it'd be really, really slow.)
Is this a faster version of rm, optimized for speed, like FUC's rmz (https://github.com/SUPERCILEX/fuc)? I was hoping that it could do that, seeing this is written in rust (hopefully for performance)
1: https://specifications.freedesktop.org/basedir-spec/basedir-...