I'm trying to write a safer alternative to rm that moves files into $HOME/temp/trash instead of deleting them immediately. It also has options to list the trash contents and permanently clear them. The current function uses mv -i and supports commands such as del -show and del -clear. What bugs, edge cases, or safety improvements should I address before relying on it?
5 Answers
Be careful with the destructive parts. `rm -fr "$trash"/*` does not match hidden files, has no confirmation, and permanently deletes the contents. The function should check that creating the directory succeeds, reject attempts to trash the trash directory or one of its parents, and check the result of every `mv`. Also use `printf '%sn' "object $object not found"` so a filename cannot be interpreted as a format string. Adding `--` to commands helps with names beginning with a dash, although proper argument parsing is still needed.
The trash directory needs collision handling. Two different paths can contain files with the same basename, and moving both into one flat directory can cause `mv -i` to prompt, leave a file unmoved, or risk replacing an existing item. A robust trash implementation should generate unique names and record each item’s original path so it can be restored. It should also consider files on different filesystems, where `mv` may fall back to copying and deleting.
There are several important Bash issues here. `for arg in $@` must be changed to `for arg in "$@"`, otherwise spaces and wildcard characters in filenames will be split or expanded. The option checks also use `$1` instead of `$arg`, so every iteration examines only the first argument. In addition, `return 0` inside the option branch exits the entire function immediately. Use proper option parsing, or at minimum process options consistently before the filenames.
Rather than inventing a trash format, consider using the desktop trash specification through an existing command such as `gio trash`. That already handles duplicate names, original locations, restoration metadata, hidden files, and separate volumes more correctly than a single directory plus `mv`. If you still keep this function, treat it as a simple personal convenience rather than a complete replacement for a system trash implementation.
That makes sense. The main goal was to avoid accidental permanent deletion, but using an established trash implementation would avoid many of the metadata and collision problems.
This function does not replace `rm` for scripts or aliases. A script that explicitly invokes the system command will still delete normally; a safer wrapper cannot reliably protect every program that calls it. If the goal is only interactive safety, an interactive shell function can be useful, but scripts should use an explicit trash command and check its exit status.
I intended the options to come first, but I see that the current loop still handles mixed arguments and filenames incorrectly. I’ll rework the parsing instead of relying on that assumption.