> Launch CLI to restore or flush elements: `rmt trash_display` or `rmt td`
> Flush all element from the trash: `rmt trash_flush`
Those need to be dash-style options. Because if someone runs a `rmt *` in a directory and there's a trash_flush file inside, it will NOT do what one expects and will be destructive.
This is why options are traditionally prefixed with dashes. (Yeah sure, you have the same problem if you have a file that starts with dash, I already hear someone point out.)
Since you suggest to alias rm to rmt, your application needs to behave like rm and have a similar UI.
I think the trash interaction command needs to be a different main command, actually. No matter what you call the option, someone can make a file with that name.
(I'm always half-tempted to suggest that a "strict mode" shell should require all paths in arguments to start with either / or ./ so that anything else is unambiguously not a file.)
(I spent a bunch of time with a file named -i in my home directory, you know, just in case.)
At least globbing should return fully qualified paths (not sure there is an established term for `(<directory>/)+<file>' paths, as opposed to `<file>` ones).
While most folks don't use it anymore, there is already an 'rmt' command[0]:
Rmt is a program used by the remote dump(8), restore(8) or tar(1)
programs in manipulating a magnetic tape drive through an
interprocess communication connection. Rmt is normally started up
with an rexec(3) or rcmd(3) call.
The rmt program accepts requests specific to the manipulation of
magnetic tapes, performs the commands, then responds with a
status indication. All responses are in ASCII and in one of the
following two forms.
Depending on the platform, this could cause a name collision with unexpected results.
Not telling you what to do, just that you should be aware.
Thank you for your comment, I try to get as close as possible to the signature of the real rm command in order to facilitate aliasing, plus I have many ideas to improve my project that are not necessarily available on rip
I would write to the author of `rip` and ask if you can take the project (including the memorable/cool name) over.
`rip` seems unmaintained (three open PRs from one to five years old). It has a name that doesn't clash with an existing *nix command and people seem to also ask for the same thing since its inception (see issue #3 from 2016).
I don’t currently have a project on deck that I’d like to Show HN but whenever I have one I will absolutely post it as “Show HN: XYZ an alternative to ABC, NOT written in Rust” just to see what would happen.
Debatable in Show HN having the implementation language kinda makes sense if you want to find people knowledgeable/interested in said language to contribute.
When was the last time you saw a “written in” be followed by PHP, Perl, Ruby, Python, C, or even JavaScript? I only see Rust as the language mentioned which makes me think the poster is looking to ride the Rust is popular train rather than looking for collaborators.
The benefit of rmt over trash-cli is that rmt has almost the same set of arguments as the rm command, and it is easier to alias between rm and rmt than thrash-cli. Also, rmt is written in rust and, therefore, more easily installable because you have to move the binary to usr/local/bin than trash-cli; it is necessary to install a python interpreter.
In most situations installing trash-cli and its dependencies is a single command (apt/dnf/etc), while with rmt you need to pick the right tarball for your system, download it, unpack it and then install the binary, or manually build it from source.
It's my first project in rust, I didn't really know how to go about getting the most practical installation possible. But thanks for the feedback, I'll work to make the process easier.
This was my initial idea but unfortunately there can be name conflicts, if two files or folders have the same name, this idea does not work anymore. Also, I wanted to be able to keep the initial path to restore the element directly where it was deleted.
When a person delete an item, I get all the information that are interesting for me (https://github.com/AmineZouitine/rmt.rs/blob/main/src/trash_...), and then I move it in a .trash folder in which I rename it with a hash (the hash is made with several parameters to avoid any collision), I then store the information in a database sqlite :)
Hi, thanks for your comment! I fix a lot of things with the numerous feedbacks, and I have a lot of ideas to make the project really interesting and different from what we can find :D
Thanks ! I have many ideas to make the project much more interesting, including adding automatic flush (that the user will have configured), the ability to compress the file before entering the trash etc ...
Do you have any ideas in mind?
This is a great idea! I hadn't thought about it.
I'm currently fixing the major bugs and refactoring the code a bit, and when I finish that, I'll get to your idea, I find it really interesting.
This was my initial idea but unfortunately there can be name conflicts, if two files or folders have the same name, this idea does not work anymore. Also, I wanted to be able to keep the initial path to restore the element directly where it was deleted.
> Launch CLI to restore or flush elements: `rmt trash_display` or `rmt td`
> Flush all element from the trash: `rmt trash_flush`
Those need to be dash-style options. Because if someone runs a `rmt *` in a directory and there's a trash_flush file inside, it will NOT do what one expects and will be destructive.
This is why options are traditionally prefixed with dashes. (Yeah sure, you have the same problem if you have a file that starts with dash, I already hear someone point out.)
Since you suggest to alias rm to rmt, your application needs to behave like rm and have a similar UI.