trash it, see it, put it back, empty it. Four verbs over the native Trash, the same one Finder shows.
brew install adriangalilea/tap/trashmacOS hides ._ metadata files in the Trash from Finder: thousands can sit in an empty-looking Trash, Empty Trash greyed out, holding bytes on disk indefinitely. trash list counts them; trash empty deletes them and states exactly what goes.
Every trashed file carries its origin. trash restore file returns it exactly where it lived, and trash list shows what is in the Trash, since when, and from where. Files land in the same Trash Finder shows, through the same system call Finder uses.
No overwrites, no guessed destinations. A file trashed by Finder, a directory that no longer exists, an ambiguous name: each stops the restore with an explanation and the exact command to run instead. Deleting forever only happens in trash empty, after asking.
Yes, shadowing a system binary feels uneasy. Here it is safe by construction: trash file runs through the same system call Apple's own tool uses, so the base case is identical rather than imitated, and the subcommands occupy only the space Apple left empty. Remove the binary and PATH falls back to /usr/bin/trash: you lose the extras, never the safety. Found a case where the two disagree? Say so in feature requests below.
No requests yet. Propose the first one.
empty and list see what Finder cannot. macOS hides AppleDouble ._ metadata files in the Trash from Finder and from every app built on Foundation: a Trash can hold thousands of them while Finder shows it empty and greys out Empty Trash, leaving the bytes on disk indefinitely. trash list now reports them ("+ N hidden ._ metadata files invisible to Finder"), and trash empty deletes them with the rest, stating the count in its confirmation. Empty means empty.brew install adriangalilea/tap/trash. The formula builds from the tagged source; upgrades arrive with brew upgrade like everything else./usr/bin/trash: empty. Scripts and pipes never see a difference. The trashed: <origin> breadcrumb prints to stderr, where terminals still show it, so shell history keeps doubling as an undo log.trash command with a real Put Back. trash file moves to the native macOS Trash through the same API Finder uses, and records where the file came from; trash restore file puts it back exactly there. trash list shows what's in the Trash, since when, and from where; trash empty asks before deleting anything forever.dup.txt on a name collision, it still goes back to its own origin.list says so, restore asks for an explicit destination instead of guessing, and Finder's own Put Back keeps working for those.trash-* scripts. Run trash bare and the whole surface prints; no more separate commands to remember. It deliberately shadows Apple's /usr/bin/trash: the base case is identical by construction, and if the binary is ever missing, PATH falls through to Apple's and only the extras are lost.No requests yet. Propose the first one.
