[Discuss] Goals and Philosophy?

[coolaj86]

Background / My Use Case

I'm working on https://webinstall.dev, and my goal is to basically publish the full suite of "modernutils" (as opposed to coreutils) - stuff like rg, lsd, curlie, sd, fd, etc, as well as programming environments (node, go, deno, flutter, etc), which are built as self-contained binaries and can easily be installed cross-platform.

I'm interested in a replacement for rm primarily because Windows doesn't have any sane rm-like thing (of course), but I also love some of the benefits that rip has over rm.

However, I also have some thoughts as to what I believe would make it an even more friendly and easy-to-adopt tool.

Trashes

I love what you're doing here in terms of "the graveyard", but I really wish it just used the system Trash folder by default (Windows, Mac, Linux, etc). Is there are reason to not do that?

-r

Also, since this is just moving things around, it seems like -r is automatic. How about just putting in a -r that gets ignored?

-f

I don't actually remember what -f does. I think it allows you to delete files that you own even when the write bit is off? Are you opposed to having a flag for that?

alias

You probably shouldn’t alias rm to rip.

I get this, but I'm also working on an online video course (part of the inspiration for webinstall.dev, actually) and because I have to teach my students a finite number of things, it's much easier to have them install modern tools (with aliases to the ancient ones) than to teach them tools that "no one else uses".

Obviously it's not even possible to alias without -rf support.

I believe that this project would benefit more people if explaining the benefit were as simple to explain as other "modernutils" tools like rg, lsd, curlie, etc, which are all basically:

a modern, cross-platform, drop-in replacement for X that also does Y

What's your Goal?

I read the readme completely, but I'm not clear on your "why" and motivations. What's the driving force?

I love the idea of rip. It looks like it's a very much needed project, and still very young and perhaps open to new use cases like mine.

Are you open to any of these suggestions? If so which?

If there are some of these suggestions that you're really not open to, and you've got a compelling reason as to why, I'd love to hear it, consider it, and see if I can get behind it.

[nivekuil]

On 2 September 2020 21:04, AJ ONeal ***@***.***> wrote: # Trashes I love what you're doing here in terms of "the graveyard", but I really wish it just used the **system Trash folder** by default (Windows, Mac, Linux, etc). Is there are reason to not do that?

Each of these environments has their own trash spec and rip implements none of them. I could give a number of pro tanto reasons like simplicity and extensibility, but the conclusive reason is that I prefer pragmatism over propriety. I'd rather do a good enough job once than a complex job three (or more) times for the same functional effect. I have no particular opposition to patches implementing those specs, at which point it could make sense to use the trash folder by default. The exception may be Linux, for which the XDG spec doesn't specify any automated trash collecting system, so I think it still makes sense to piggyback on some well-known tmp dir as defaults should cater to the lazy.

# -r Also, since this is just moving things around, it seems like `-r` is automatic. How about just putting in a `-r` that gets ignored?

nack; if the goal is to accommodate existing habits then this is better done in some wrapper function. I am not aware of any software that has made the decision to deliberately bloat its interface with no-op flags. As far as I can tell this is more or less software malpractice. And there's an XY problem rearing its head here: why would you want to do this?

# -f p I don't actually remember what `-f` does.

The man page is a little cryptic for `-f`: `ignore nonexistent files and arguments, never prompt` As far as I can tell it means "never complain to the user".

I think it allows you to delete files that you own even when the write bit is off?

It just bypasses the prompt. `rm` isn't actually affected by write permissions on the file, since it really is just a thin wrapper over the `unlink` system call, which only modifies metadata, not the data blocks of the inode.

Could you add a flag for that?

nack; same as above

# alias > You probably shouldn’t alias rm to rip. I get this, but I'm also working on an [online video course](https://beyondcodebootcamp.com) (part of the inspiration for webinstall.dev, actually) and because I have to teach my students a finite number of things, it's much easier to have them install modern tools (with aliases to the ancient ones) than to teach them tools that "no one else uses".

One doesn't need a teacher to learn questions of the form "how do I use X". The real worth of a teacher is in answering questions of the form "why/when/whether I should use X?", to highlight those tacit and lurking questions that students wouldn't appreciate on their own. Even if the goal is to teach people how to pass interviews, the "good" companies train interviewers to test for understanding rather than knowledge, and a student would be ill-served by a teacher who merely "has them" do things as opposed to a teacher who encourages them to examine and question the reasons behind doing things. I don't care whether or not you include my software in your program, but for the sake of your students I encourage you to not view comfort as a goal. Instead, it might be useful to teach the confidence to dive into man pages.

Obviously it's not even possible to alias without `-rf` support.

As mentioned above, you can use a shell function wrapper instead of an alias if you really want this behavior, but you would be emulating the wrong semantics; see below.

I love the idea of this. It looks like it's a very much-needed project, but still very young and perhaps open to new use cases like mine. I believe that your project would benefit more people if it were as simple to explain as other tools like `rg`, `lsd`, `curlie`, etc "a modern, drop-in replacement for _X_ that does _Y_".

I think the source of some confusion here is that semantically, `rip` is not a shiny `rm`, but rather a specialized `mv`. I use `rg` and `fd` all the time because they're faster and more ergonomic, and those can be considered replacements for the corresponding coreutils tools because they convey the same intent: "look through data blocks" and "look through metadata" respectively. `rm` actually means "remove the file", while trashing mean "move it somewhere else". This is just like `mv` but is more convenient in situations where you don't care about moving the target to a particular location, like an singulary `mv`.

I read the readme completely, but I'm not clear on your "why" and motivations. What's the driving force?

Fun. `rip` is written in Rust because it's fast (-er than e.g. Python implementations which have to load libraries on startup), and fast is fun. It dumps the stuff into /tmp (room for improvement here perhaps) because pretty much every system already has some sort of cleanup strategy configured for /tmp, and manual configuration isn't fun. The interface is small because simple is fun, and that likely makes it a decent project to learn Rust from (I wrote it to learn Rust) and that's pretty fun too. The whole thing is a themed pun because themed puns are fun. And of course, data loss from `rm` isn't fun.

[coolaj86]

Each of these environments has their own trash spec and rip implements none of them.

Indeed, It's a bit hairier than I imagined.

For reference

On Mac trashing is part of the core SDK and on Windows it requires syscalls. It could be as simple as "just move it to the user trash folder", but there are hints of nuance details that make that not always true.

• MacOS: https://github.com/sindresorhus/recycle-bin/releases
• Windows 8+: https://github.com/sindresorhus/recycle-bin/releases
• Linux: https://github.com/sindresorhus/trash/blob/master/lib/linux.js (not native, but follows UUID rules)

Mac Trash Folder brief (needs 3rd party binary)

1. Resolve the canonical path of the file.

   /Users/me/github.com/example/example/main.bin

2. Search up a level until .Trash is found (each volume and user has its own)

   /Users/me/github.com/example/example/.Trash{es}
   /Users/me/github.com/example/.Trash{es}
   /Users/me/github.com/.Trash{es}
   /Users/me/.Trash{es}

3. If .Trash, use that directly, otherwise use .Trashes/$UID (a volume may have multiple trashes)

Windows Trash Folder brief (Workable)

This should work on all modern windows systems:

$path = "<path to file>"
$shell = new-object -comobject "Shell.Application"
$item = $shell.Namespace(0).ParseName("$path")
$item.InvokeVerb("delete")

This may work...

1. Get the SID whoami /user
2. move to C:\$Recycle.Bin\%SID%

Linux Trash Folder brief (Workable)

• $XDG_DATA_HOME/Trash/files (meaning ~/.local/share/Trash/files)
  • and .Trash-${UID}/files/${RANDOM_UUID} on removable volumes
• needs a ${TRASHDIR}/info/${RANDOM_UUID}.trashinfo with
  • [Trash Info]\nPath=${filePath.replace(/\s/g, '%20')}\nDeletionDate=${ISO_TIMESTAMP}