We’ve all had our fair share of accidentally removing files. Instead of<p><pre><code> rm my_file.txt
</code></pre>
or<p><pre><code> rm -rf my_folder
</code></pre>
we do<p><pre><code> del my_file.txt
</code></pre>
or<p><pre><code> del my_folder
</code></pre>
where you can define your Bash alias for `del` in ~/.custom_aliases as<p><pre><code> function del() {
mv $* ~/.Trash
}
</code></pre>
which simply moves your files/folders to the trash such that you can recover them easily later.<p>What’s your alternative?
While not an alternative, please bugfix your bash:<p>mv "$@" ~/.Trash/<p><a href="https://github.com/koalaman/shellcheck/wiki/SC2086" rel="nofollow">https://github.com/koalaman/shellcheck/wiki/SC2086</a>
For Linux users: also look into the trash-cli [1] package, which complies with the FreeDesktop.org trash specification and remembers the original path, etc. so that trash items can be restored even with filename collisions. Then it's<p><pre><code> trash-put my_file.txt
</code></pre>
[1] <a href="https://github.com/andreafrancia/trash-cli" rel="nofollow">https://github.com/andreafrancia/trash-cli</a>
I've never liked the idea of a trashcan, and usually shift-delete when I'm in the gui. Deleting shouldn't be done casually, but a ui shouldn't second guess a user any more than it has to.
rm is for removing stuff. If you don’t want to remove the file, use mv.<p>Take care when entering commands, if it’s important that you don’t mess up, spend an extra second. Don’t run around shooting rm -rf as super user.<p>With great powers comes great responsibility.
My “alternative” to rm is to use mv directly. I just mv files aside whenever I am not 100% confident they are safe/ready to delete permanently.<p>Personally I’m not a fan of shell environment customizations like this because they are often fragile and may vary between systems. I like to know exactly what commands I’m executing.
I like using the ‘trash’ command through Homebrew, on macOS Terminal:<p><a href="http://hasseg.org/trash/" rel="nofollow">http://hasseg.org/trash/</a>
> What's your alternative?<p>When I execute rm I mean to delete. When I'm not sure I expyre[1] the path: <a href="https://github.com/lonetwin/expyre" rel="nofollow">https://github.com/lonetwin/expyre</a><p>[1] shameless plug -- but you did ask ;-)
I too have my share of reinventing the trash functionality :)<p>garbage-io has some features that scratch my own itches:<p>- Trash files with the same name without clashing
- Delete things from trash directory base on deletion time and file size
- Hide the deleted files/directories before moving them, in case moving them takes a long time (I later think this was a bit over the top...)
- The smart deletion can also be used for e.g. ~/Downloads<p>I do feel that a better approach would be something that works alongside the trash functionality instead of replacing it, though.<p><a href="https://gitlab.com/phunehehe/garbage-io" rel="nofollow">https://gitlab.com/phunehehe/garbage-io</a>
My alternative is to think carefully before hitting return. As a bonus, this works for other commands, too.<p>Also, '\rm', as many distributions insist on aliasing 'rm' by default.
How do you manage your ".Trash" folder? Who is in charge of deleting it's content? Do you do it periodically or based on some other event?
If you spend most of your time in emacs, and like to delete/move files in dired, you can use<p>(setq delete-by-moving-to-trash t)<p>to achieve the same effect.
nilfs2 is my alternative. It's a log-based filesystem that results in continuous checkpoints that can be upgraded to mountable snapshots at any time. Realized you blew away a file you needed? Made large modifications you wish you hadn't? Just find an earlier checkpoint and your good to go.<p>Backups too. Nothing replaces backups.
I already have an alternative for Windows users. Doesn't provide any data retention mechanism, but still helpful:<p><pre><code> $ ls -l /usr/local/bin/del
lrwxrwxrwx 1 root root 13 Mar 18 12:46 /usr/local/bin/del -> /usr/games/sl</code></pre>
This was one of the first things I realized I had to do back when I installed a Red Hat 3.0 for the first time.<p>My alias was for rm itself. I replaced it completely, as the habit of using rm is hard to forget. Today I don’t use an alias anymore.
This is another example that shows that Bash (and similar shells) should not be used for scripting.<p>It's great for the command line, but for scripting there are much better, cleaner, faster and safer alternatives.