Organising files

Cleaning up dead shortcuts

Updated 2026-07-31 · 3 min read

Move enough folders and you leave a trail of shortcuts pointing at nothing.

Broken symlinks

find ~ -type l ! -exec test -e {} \; -print 2>/dev/null

Reads as: symlinks whose target does not exist. The standard dead-link finder.

Delete them once reviewed:

find ~ -type l ! -exec test -e {} \; -delete 2>/dev/null

Broken Finder aliases

Aliases are trickier — they are small data files, not symlinks, and store a file ID plus a path. Finder tries hard to resolve them (that is their advantage), so a truly broken alias usually means the original was deleted, not just moved.

Finder itself reports these: double-click a broken alias and it offers to Fix Alias or delete. There is no clean one-liner because aliases are an opaque format; the practical approach is Finder's own dialog, or recreating the alias once you locate the original.

Finding what an alias points to

osascript -e 'tell app "Finder" to get POSIX path of (original item of (POSIX file "/path/to/alias" as alias))'

If that errors, the original is gone.

After a big reorganisation

Symlinks in dotfiles and config break silently — a moved tool, a renamed home folder:

find ~/.config ~/bin -type l ! -exec test -e {} \; -print 2>/dev/null

Dock items and Login Items pointing at moved apps also dangle; recreate them from the current location.

Prevention

Aliases survive moves within a volume (they track the file ID); symlinks do not (they store a path). For links that must survive reorganisation, prefer aliases — or keep symlinks relative and move whole trees together.

Common questions

How do I find broken symlinks on a Mac?

find ~ -type l ! -exec test -e {} \; -print lists links whose target is missing; add -delete to remove them.

Why do Finder aliases survive moving but symlinks break?

Aliases store the file's ID and resolve by identity; symlinks store only a path.