The “trash” Command
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 folder in ~/Library/Developer/Xcode.
[…]
But
rmneeds to enumerate every file and directory within DerivedData in order to delete them. The more files there are, the longer this will take.It’s faster to move the DerivedData folder to the Trash. You could do this from the Finder, but I prefer to install Ali Rantakari’s
trashutility.
macOS 14 added a built-in /usr/bin/trash command.
The good: they added a unix
trashcommand 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.
Previously:
Update (2025-09-25): Vítor:
I just tested on Sonoma 14.6.1 and 14.8 virtual machines and can confirm that /usr/bin/trash does not exist on Sonoma 14, as reported.
The man page on Sequoia says it was added in Sonoma, but that appears to be incorrect. The Tahoe man page says it was added in Sequoia.
8 Comments RSS · Twitter · Mastodon
Another Apple half-assed shot show. They can’t get one thing working properly, down to the Unix command. Embarassing.
The excerpt made it seem like emptying the Trash had some fast path for deeply nested file deletion, but the blog post stops at just moving the folder to the Trash. My guess is that the actual emptying/deletion, when gotten around to, would be as slow or slower than rm.
Actually, I'm not sure about that. I think I remember cases where emptying the Trash from Finder was faster.
@vintner You may be right, but the important thing in this context is that emptying the Trash won’t block your development workflow the way that “rm -r” would. The “trash” command runs very quickly, allowing you to get back to whatever you were trying to do with Xcode. You can empty the Trash later: as you’re walking away from your computer for a break, maybe. Or you can configure the Finder to automatically delete things from the Trash after 30 days.
"The bad: The Finder completely wigs out when you use it - disappears a different folder from the parent folder, leaving the trashed folder showing."
Ridiculous, but totally expected for Apple these days. I guess the "trash" is actually the command itself!
I regularly get permission errors and/or some file is in use when trying to delete Mac apps I put in the Trash. Sometimes it says the App store receipt in the app bundle is in use.. sometimes the alert says something else.
Often the trashed app has been in the Trash for days, weeks even and I forgot about it. How could the Mac App Store receipt still be in use after all that time?
I find it kind of annoying to have to use sudo rm but otherwise there is no way to delete these files.
> the "put back" feature only works when trashing files through Finder.
1) does the new trash command enable it?
2) why doesn’t the system API (unless it’s generally for moving files rather than specifically for moving to trash)?
3) wouldn’t this simply be an extended attribute the Finder sets?
(Apparently not, which might answer all three: the Finder puts the trash metadata in .DS_Store, and also doesn’t expect other processes to write there. Oof.
Kinda suggests this code hasn’t been touched since before Tiger, which I believe is the release that introduced xattr.)
As a long time Windows admin, I'm quite familiar with Explorer having no idea what's actually going on. But since it's based on Internet Explorer, the refresh command works.
Seems we have come full circle. Now it's Apple with the legacy OS they keep painting over without properly renovating.
