{"id":49039,"date":"2025-08-26T14:58:29","date_gmt":"2025-08-26T18:58:29","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=49039"},"modified":"2025-09-25T16:42:54","modified_gmt":"2025-09-25T20:42:54","slug":"the-trash-command","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/08\/26\/the-trash-command\/","title":{"rendered":"The “trash” Command"},"content":{"rendered":"

Benjamin Esham<\/a>:<\/p>\n

\n

Every iOS and Mac developer is familiar with the situation: Xcode has gotten itself wedged somehow and the only solution is to blow away the DerivedData<\/tt> folder in ~\/Library\/Developer\/Xcode<\/tt>.<\/p>\n

[…]<\/p>\n

But rm<\/code> needs to enumerate every file and directory within DerivedData<\/tt> in order to delete them. The more files there are, the longer this will take.<\/p>\n

It’s faster to move the DerivedData folder to the Trash.<\/strong> You could do this from the Finder, but I prefer to install Ali Rantakari’s trash<\/code> utility<\/a>.<\/p>\n<\/blockquote>\n\n

macOS 14 added a built-in \/usr\/bin\/trash<\/tt> command.<\/p>\n\n

Peter N Lewis<\/a>:<\/p>\n

\n

The good: they added a unix trash<\/code> command to macOS. Nice! The bad: The Finder completely wigs out when you use it - disappears a different folder from the parent folder, leaving the trashed folder showing. The Finder display is borked, if you close and reopen the window the window is correct and the command worked as expected.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n