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:
3 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.
