trash-cli VS grub-btrfs

There's a Freedesktop specification for trashing files that you may consider adhering to: https://specifications.freedesktop.org/trash-spec/trashspec-...

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.

Hard deleting was more necessary on the past when storage was so tiny and expensive, but now we not constantly fighting for space anymore. So treat a rm (and the Unix tradition as a whole) as a product of its time, move undesirable files to the trash instead, you can use this trash-cli for linux.

Not related to Docker, but use the trash-cli trash command to have the recycle bin in the terminal as well.

i ended up using shell-safe-rm plus trash-cli and my own wrapper script around rm that verifies some rules like for example the argument don't start with '/' , if i want to delete for example /home/shin/.local/somefile then the script will not let me and suggest to cd to /home/me/.local and delete from there , same if i do rm /var/somedir.

They're probably talking about something like this rather than a GUI file manager

It's a bad idea to alias rm. You will get trouble on a machine that has no alias. Use trash-cli instead. It's much safer than rm. BTW, don't alias trash as rm because they are different.

For Linux there's [trash-cli](https://github.com/andreafrancia/trash-cli/). Doesn't seem to work for MacOS per this issue (https://github.com/andreafrancia/trash-cli/issues/284), but it suggests to use https://hasseg.org/trash/

Use trash-cli for all your rm -rf needs!

There are a number of foss tools that work with the freedesktop trashcan concept on Linuxes/BSDs, like https://github.com/andreafrancia/trash-cli. Bunch of desktop envs' programs also use this, so it's nearer to OS-wide standardized behavior.

Afaik the proper solution is to use https://github.com/Antynea/grub-btrfs/blob/master/initramfs/readme.md and/or rollback the root to a snapshot.

In fact I’m pretty knowledgeable around btrfs and snapshot-tools as well. :D I codevelop https://github.com/Antynea/grub-btrfs.

Something I noticed is that the instructions here before step 2 suggest that the files /etc/initcpio/install/grub-btrfs-overlayfs and /etc/initcpio/hooks/grub-btrfs-overlayfs might exist, and they don't for me. Worth noting that I installed through pacman, which may be a reason they don't exist if I'm reading those instructions correctly.

In Debian, I see that there is a custom installer "Spiral Linux" (https://spirallinux.github.io) with non-default settings that achieves the same kind of mechanism using "grub-btrfs" (https://github.com/Antynea/grub-btrfs) in combination with "snapper-rollback" (https://github.com/jrabinow/snapper-rollback) and a BTRFS subvolume layout suggested by the Arch wiki (https://wiki.archlinux.org/index.php/Snapper#Suggested_filesystem_layout).

grub-btrfs

When the issue first arrived (around 01/11/2023, IIRC), I did try posting an "Issue" on the GitHub page for grub-btrfs (located here), & more specifically on Issue #254, however, for whatever reason (at that time) I wasn't able to make a post on that Issue/forum.