grep invalid option -- P on Mac: What Works Instead

A one-liner copied from a Linux answer fails on the first flag:

$ grep -oP 'id=\K\d+' in.txt
grep: invalid option -- P
usage: grep [-abcdDEFGHhIiJLlMmnOopqRSsUVvwXxZz] [-A num] [-B num] [-C[num]]
	[-e pattern] [-f file] [--binary-files=value] [--color=when]
	[--context[=num]] [--directories=action] [--label] [--line-buffered]
	[--null] [pattern] [file ...]
$ echo $?
2

The grep on a Mac is BSD grep, GNU compatible 2.6.0-FreeBSD, and the "GNU compatible" part stops at -P. Apple's source makes it plain: in text_cmds grep.c, the option string inside #ifdef __APPLE__ has no P. The Stack Overflow question about this dates from 2013 and had 92,938 views when I pulled it today. Its answers are the usual list: install GNU grep, use perl, use pcregrep, use egrep.

The same grep.c file shows something the answers don't mention. On Apple builds, both basic and extended mode add a flag called REG_ENHANCED. So the stock grep -E already understands \d, \s, \w and lazy .*?. Some -P patterns don't need -P on a Mac at all. I tested seven common PCRE patterns against the stock grep and six substitutes on this Mac mini (macOS 26.4.1) to see which ones.

Seven patterns, eight tools

The test file had four lines: order id=4821 status="shipped" note="late", an email address, API_KEY=sk_live_9f3a token and a price. Every tool ran with -o (print the match only), called by absolute path.

Pattern	What it needs	/usr/bin/grep -E	ggrep -P, pcre2grep, rg -P, git grep -P, perl	rg (no -P)
\d+	digit class	works	works	works
\s\d+\.\d+	space class	works	works	works
".*?"	lazy repeat	works	works	works
id=\K\d+	\K (drop prefix)	no output, exit 1, no error	works	parse error
\w+(?=@)	lookahead	error, exit 2	works	parse error
(?<=API_KEY=)\w+	lookbehind	error, exit 2	works	parse error
"\w+"(?! note)	negative lookahead	error, exit 2	works	parse error

The five tools in the fourth column gave the same output on every row: GNU grep 3.12 from Homebrew (ggrep), pcre2grep 10.47, ripgrep 15.1.0 with -P, Apple's git grep -P (git 2.50.1, Apple Git-155) and the system perl 5.34.1.

The stock grep's boundary matches what man re_format lists under "ENHANCED FEATURES": the \d \s \w shortcuts and their capitals, \b and \< \>, \Q…\E, non-capturing groups, and "minimal repetitions" (lazy *? +?, extended mode only). Lookaround and \K aren't on the list. Lookarounds fail loudly with repetition-operator operand invalid. \K is the bad one: the pattern compiles, matches nothing, and exits 1, the same as a search that found nothing. In a script that reads like "no ID in the file".

The 2023 version of the question (11,970 views) used grep -P '\((.*?)\)' to pull a UUID out of parentheses. The accepted answer says to drop PCRE and use awk. On a Mac that pattern only needed -E:

$ echo 'device (D96F) and (A1B2)' | grep -oE '\(.*?\)'
(D96F)
(A1B2)

The catch: the same pattern means something else on Linux

If the script only runs on Macs, that's the end of it. If it also runs on Linux or in a Linux CI container, the enhanced syntax is a trap, because GNU grep reads the same characters differently and mostly doesn't fail:

$ ggrep -oE '\d+' in.txt
ggrep: warning: stray \ before d
d
d
d
d
$ echo 'device (D96F) and (A1B2)' | ggrep -oE '\(.*?\)'
(D96F) and (A1B2)

In GNU extended mode, \d is the letter d, with a warning on stderr. .*? is a greedy .* made optional, so the two matches become one. Both exit 0. The lazy case doesn't even print a warning.

The enhanced flag also stops at grep. On the same Mac:

$ echo 'id=4821 x' | sed -E 's/\d+/N/'
iN=4821 x
$ bash -c '[[ "id=4821" =~ id=\d+ ]] && echo match || echo no match'
no match

macOS sed treated \d as a literal d and replaced the one in id. That's the same class of quiet BSD-vs-GNU difference as sed's -i argument, except this one doesn't print an error. The system bash 3.2 and zsh =~ didn't match either. A \d that works in your terminal's grep doesn't carry over to the next tool in the pipe.

So for portable patterns, the old advice still holds: write [[:digit:]], [[:space:]] and [^"]*. The accepted answer on converting -P to -E says exactly that. It runs the same on BSD grep, GNU grep and busybox.

The substitutes, in the order I'd reach for them

GNU grep from Homebrew. The top answer on the 2013 thread (157 votes, not the accepted one) and the least change to the script:

brew install grep
ggrep -oP 'id=\K\d+' in.txt          # 4821
# or put GNU grep first under its real name
export PATH="/opt/homebrew/opt/grep/libexec/gnubin:$PATH"

The gnubin line only helps shells that read your profile. A launchd job gets /usr/bin:/bin:/usr/sbin:/sbin unless you set it (details in launchd plist environment variables), so it will still find /usr/bin/grep. For scheduled jobs, call /opt/homebrew/bin/ggrep by full path. Homebrew's g prefix is the same convention as coreutils, which is also how you get the missing timeout command.

perl, with nothing to install. The accepted answer from 2013 still works with the system Perl:

perl -nle 'print $& while m{id=\K\d+}g' in.txt     # like grep -oP
perl -nle 'print if m{(?<=API_KEY=)\w+}' in.txt   # like grep -P

It gave the same output as ggrep -P on all seven rows. The downside is that every grep flag (-r, -l, -c, -i) has to be rebuilt in Perl.

git grep -P inside a repo. Apple's git is built with PCRE, so git grep -P works on a stock Mac with the command line tools. It searches tracked files by default. Outside a repo it refused my test file with fatal: ... is outside the directory tree until I ran it inside one.

pcre2grep and ripgrep. pcre2grep comes with brew install pcre2. The 2013 answers point to pcregrep from the old pcre package, which is PCRE1 and no longer developed. ripgrep needs -P for lookaround and \K: without it, it stops with a parse error, which is at least loud.

egrep is not a substitute. One answer on the 2013 thread suggests it. On macOS it's the same BSD binary as grep -E, so it has the same enhanced features and the same missing lookaround.

One more place -P works: AI agent shells

This error has a second source now. In Claude Code on macOS, the grep in the agent's shell is a function that runs a bundled ugrep, and ugrep accepts -P. In this session, grep -oP 'id=\K\d+' printed 4821. The same line in a script, in Terminal, or in a launchd job runs /usr/bin/grep and fails. I wrote up how that grep wrapper also skips gitignored files last week. If an agent tells you a grep -P command was tested, check which grep tested it with type grep.

This is the same pattern as the other BSD gaps I've measured here, such as stat's -c and cp's --parents: the error message is the easy case. Here the harder cases are \K giving an empty result on the Mac and \d matching the letter d on Linux, both with an exit code that looks normal.

Sources: every command above ran on 2026-10-03 on a Mac mini (macOS 26.4.1, build 25E253) against a four-line test file in a throwaway folder, using /usr/bin/grep (BSD grep 2.6.0-FreeBSD), GNU grep 3.12 with PCRE2 10.47 (Homebrew, installed for this test), pcre2grep 10.47, ripgrep 15.1.0, /usr/bin/git 2.50.1 (Apple Git-155), /usr/bin/perl 5.34.1, /usr/bin/sed, /bin/bash 3.2.57 and zsh. Tools were called by full path because the grep in my agent shell is a wrapper. The list of enhanced features is from man re_format on the same Mac, and the option string and REG_ENHANCED lines are from Apple's open-source text_cmds repository. Stack Overflow vote and view counts come from the Stack Exchange API on the same day.