The find Command on macOS: What’s Different from Linux

macOS ships the BSD version of find at /usr/bin/find, not the GNU findutils version most Linux distributions use. Most of what you know carries over unchanged — but a handful of habits from Linux tutorials fail in specific ways, and the error messages don’t always make the reason obvious. Here’s exactly what differs, checked on macOS 26.5.2.

What works the same

Start with the good news, because it’s most of the command. -maxdepth, -mindepth, -type, -name, -iname, -delete, -mtime, -size, and -exec ... {} + all behave the same as on Linux. A typical one-liner runs identically on both:

find . -maxdepth 2 -type f -name '*.log' -delete

So the differences below are the exceptions, not the rule — four specific places where a Linux habit trips.

It needs a starting path

On Linux, GNU find lets you leave out the path and assumes the current directory. BSD find doesn’t — omit the path and it rejects the command before it even reads your expression:

$ find -name '*.txt'
find: illegal option -- n
usage: find [-H | -L | -P] [-EXdsx] [-f path] path ... [expression]

$ find . -name '*.txt'      # add the .
./notes.txt

The illegal option -- n is misleading — nothing is wrong with -name. find just never got the path it needs, so it tried to parse -name as the starting point. The habit to build on macOS: always put the path, usually ., right after find.

There’s no -printf

GNU’s -printf, for formatting each result, doesn’t exist in BSD find:

$ find . -printf '%p\n'
find: -printf: unknown primary or operator

For a quick listing, -ls covers most of what people reached for -printf to do:

find . -name '*.txt' -ls

For custom output, hand each match to stat. Note macOS stat uses -f with its own format letters — %z for size, %N for name — not GNU stat’s %s/%n:

$ find . -name '*.txt' -exec stat -f '%z %N' {} +
6 ./notes.txt

Extended regex is -E, not -regextype

GNU find picks a regex dialect with -regextype. BSD find has no such flag; you switch on extended regular expressions with -E, and it goes before the path rather than inside the expression:

$ find . -regextype posix-extended -regex '.*\.txt'
find: -regextype: unknown primary or operator

$ find -E . -regex '.*/f[0-9]+\.txt'
./f1.txt

As on Linux, -regex matches against the whole path, not just the filename — which is why the pattern above includes the leading directories.

No –version or other long options

BSD find doesn’t take GNU’s double-dash long options. --version and --help both error on the leading dashes:

$ find --version
find: illegal option -- -

Use man find for the reference instead. And if you genuinely need GNU find — for -printf, say — Homebrew‘s findutils formula installs it as gfind, leaving the system find untouched.

The short list: put a path after find, swap -printf for -ls or -exec stat, use -E instead of -regextype, and skip the --long flags. Everything else you know from Linux — -type, -name, -delete, -maxdepth, -exec ... + — works the same. All checked on macOS 26.5.2 against /usr/bin/find.