Show HN: Rmt an alternative to rm with trash written in Rust | Hacker News Reader

Show HN: Rmt an alternative to rm with trash written in Rust

github.com

45 pointsAmine_Ztn51 comments

Quote:

> 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.

You are totally right, thank you for the pertinent comment and I will correct that. This is one of the first cli's I had not thought of at all.

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.

Usually tools support a `--` option for that, e.g. with `rm`:

  rm -- --file-that-looks-like-a-flag

    rm ./--file-that-looks-like-a-flag

;)

(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.)

thank you for your feedback, I take it all into consideration, I will try to fix it during the day :D

At least globbing should return fully qualified paths (not sure there is an established term for `(<directory>/)+<file>' paths, as opposed to `<file>` ones).

I agree. rmt-flush and rmt-list would be great options.

Also, the `trash_` is redundant, so `rmt --display` et cetera is all enough (and please make short options like `-d` too).

Oddly enough, https://github.com/Byron/trash-rs also has this same UI issue (and is also written in Rust)

Oh, that's nice. A library providing cross-platform access to system's trash. Surprising none of the Rust-written rm alternatives used this.

I followed your advice and fixed the problems, I updated the readme and the deployment of the new version (0.1.2) should arrive in 1 hour.

I thank you for raising these points.

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.

[0] https://linux.die.net/man/8/rmt

This has a pretty serious bug with symlinks:

    > ln -s important_file.txt ./just_a_link
    > rmt ./just_a_link

This leaves "just_a_link" and instead deletes important_file.txt.

Ok thanks a lot, I'll work on fixing that!

I just fixed the problem, thanks for pointing it out! :D

There is `rip`[1] (also written in Rust) which does more or less the same? Or am I missing something?

[1] https://github.com/nivekuil/rip

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).

Don't actually alias it with 'rm' or you'll have a bad surprise waiting when you are on a different system and your muscle memory kicks in.

I even had to disable rm for non-privileged users on my systems just to get used to use trash-cli.

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.

Reminds me somewhat of trash-cli:

https://github.com/andreafrancia/trash-cli

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.

Not sure about rust stuff, but trash-cli is simply just packaged for all the commonly used distros.

https://repology.org/project/trash-cli/versions

Why not just use or alias ‘mv’ to trash?

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.

How would you use Rust with that approach?

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 :)

Nice! Now I'll just be a single missing keystroke away from accidentally deleting my files permanently.

Oh I love stuff like this. I'm always looking for that little tool that scratches itches I hadn't yet articulated, and this is one of them.

Just last night I rimraf'd something and did a double take. I deleted the right one, thankfully, but you're always one command from trouble.

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

Also in Rust: https://git.sr.ht/~mzhang/garbage — a soft-deletion CLI tool with FreeDesktop Trash compatibility.

Here is an interactive browser demo. Have fun.

https://xn--yv9h.fm/emu/?m=oACYqwLUHto9zqU25DWm97

shameless self plug:

https://github.com/bAndie91/libyazzy-preload/#recyclixso

recyclix.so is an LD_PRELOAD-able shared library intercepting file deletions and moving files to recycle bin (trash can) folder.

Seeing it creates some sort of database, this uses its own trash distinct from system's trash, right?

Yes

What OSes are supported? Does it use the standard trash locations for each OS?

It support Linux and MacOS and it use a different trash location (.trash_rmt)

Consider using The FreeDesktop.org Trash specification. It's just two screenfuls long, and would let the tool integrate with Gnome/Kde trash.

https://specifications.freedesktop.org/trash-spec/trashspec-...

Nice! Is there any desire to extend beyond original `rm` functionality?

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?

So glad you asked!

The main one is that files sent to trash are encrypted. So that a private key is required to restore them.

Ideally even the meta data is encrypted.

I've watched too many kids spy movies from the 2010s with files restored from trash!

Edit: just wanted to add I just mean via GPG! Rather than asking encryption be added to the application.

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.

Doesn't work for Windows

I'm fixing the bugs after the feedback and then I'm fixing the Windows problem, I'm using a crate that is not cross-platform for the input management

function rm(){ mv "@$" ~/.Trash }

Reply on news.ycombinator.com