skip to content

the macOS trash cli with a real put back

installsourcemacOS 13+ · free · MIT
a real put back

Every trashed file carries its origin. trashrestorefile returns it exactly where it lived, and trashlist 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.

01

features

screams before it guesses

v1.0.0
screams before it guesses

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 trashempty, after asking.

shadows /usr/bin/trash, on purpose

v1.0.0
shadows /usr/bin/trash, on purpose

Yes, shadowing a system binary feels uneasy. Here it is safe by construction: trashfile 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.

02

feature requests

vote on what's next, or propose it

proposed

0

nothing here yet

planned

0

nothing here yet

building

0

nothing here yet

03

changelog

1.1.0

added

  • brew install adriangalilea/tap/trash. The formula builds from the tagged source; upgrades arrive with brew upgrade like everything else.

changed

  • stdout is byte-identical to /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.
  • Collision renames announce themselves. When macOS renames an item inside the Trash, the breadcrumb names the Trash-side name, so restore is never a guessing game.

1.0.0

added

  • One 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.
  • Origin travels with the file. Every trashed item carries its original path in an extended attribute, so restore works across shells, across reboots, and across Trash-side renames: when macOS renames dup.txt on a name collision, it still goes back to its own origin.
  • Foreign items are handled, never guessed at. Something trashed by Finder or another tool has no recorded origin: list says so, restore asks for an explicit destination instead of guessing, and Finder's own Put Back keeps working for those.
  • Restore never overwrites. A file already at the origin, a vanished original directory, or an ambiguous name stops the restore with an explanation, not a guess.

changed

  • One binary replaces the 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.