nproc on Mac: Missing nproc Turns make -j Into No Limit

On a stock Mac, make -j$(nproc) doesn't fail. The shell prints nproc: command not found, the substitution comes back empty, and make receives a bare -j. GNU make reads that as "no limit". On this Mac mini M4 with 10 cores, a 30-file build started all 30 compilers at once. It finished in about the same time as -j10, used twice the memory, and exited 0. Nothing in the result tells you the core count was never read.

"nproc mac" gets 27 Google autocomplete completions, mostly "install nproc mac", "mac nproc command not found", and "macos nproc equivalent". The usual answer is "use sysctl -n hw.ncpu", and that answer is right. What it leaves out is what your script already did before you saw the error, and whether an Apple silicon Mac should count all its cores or only the performance ones. I measured both on macOS 26.4.1, and I went through 275 GitHub issues and pull requests that mention the error.

One note on my setup before the tests. Homebrew coreutils went onto this machine on September 29. In 9.12 the formula only adds the g prefix to commands macOS already ships, so it installs nproc under its plain name in /opt/homebrew/bin. On this Mac, a script that calls nproc works in my normal shell and fails on a stock Mac. All tests below pin PATH=/usr/bin:/bin:/usr/sbin:/sbin.

What macOS gives you instead of nproc

nproc is a GNU coreutils program. It isn't in POSIX, and macOS ships BSD userland, so it was never on the system. Here are the stock answers on this Mac (Mac16,10: 4 performance cores, 6 efficiency cores):

$ command -v nproc; echo $?
1
$ sysctl -n hw.ncpu hw.logicalcpu hw.physicalcpu
10
10
10
$ sysctl -n hw.perflevel0.physicalcpu hw.perflevel1.physicalcpu
4
6
$ getconf _NPROCESSORS_ONLN
10

Apple's sysctl capabilities page documents hw.ncpu as an alias of hw.logicalcpu_max, and hw.perflevelN as per-core-type counts where level 0 is the fastest. Apple silicon has no SMT, so logical and physical are both 10 here. Older Intel Macs with Hyper-Threading report double the physical count.

One difference matters if you install coreutils. GNU nproc honors OMP_NUM_THREADS and OMP_THREAD_LIMIT, as its manual says. With OMP_NUM_THREADS=3 set, Homebrew's nproc printed 3, while sysctl and getconf still printed 10. A fallback chain can therefore return different numbers depending on which tool it finds first.

What each idiom does when nproc is missing

The error message is the same every time, but what the shell does next depends on where $(nproc) sits in the command. I ran each pattern under bash 3.2.57 (macOS /bin/bash), sh, and zsh -f:

Pattern	What runs	Exit
make -j $(nproc) all	make -j all, unlimited jobs	0
make -j"$(nproc)" under set -e	make -j"", unlimited, script continues	0
tool -w $(nproc) -t 1s	-w takes -t as its value	tool-dependent
echo $((2 * $(nproc))) in a bash script	"operand expected"; that command is skipped, the next line runs	0
same, under sh / zsh	script aborts	1 / 127
xargs -P $(nproc) -n1 …	xargs: -P -n1: invalid	1
set -e; J=$(nproc)	script stops	127

Only the last two fail loudly. In the top row, the empty substitution disappears during word splitting, and the GNU make manual is explicit about what follows: "If there is nothing looking like an integer after the '-j' option, there is no limit on the number of job slots." Quoting it doesn't help. -j"" is still a bare -j, and set -e doesn't fire, because a failed command substitution inside an argument isn't a failed command.

The arithmetic row is the one that loses work. In a bash script, the expansion error kills only the command it appears in. If that command was your test runner, the script moves on and exits 0. agent-glovebox#6049 found that in CI: a pytest shard sized with $((2 * $(nproc))) ran zero tests on macOS and reported RC=0.

Unlimited -j was not slower, it used twice the memory

I wanted to know whether the unlimited build actually costs anything, and whether Apple's efficiency cores are worth counting. My test was 30 compiles of the SQLite 3.50.4 amalgamation (clang -O2, Apple clang 21, 5.9 s each), run through make 3.81 at six job counts, two rounds each. The machine also had its usual background load (load average 2 to 3), which is why I averaged two rounds.

Three results:

• Count the efficiency cores. -j4, the performance-core count, averaged 53.8 s. -j10 averaged 36.5 s, which is 32% faster. Sizing a build from hw.perflevel0.physicalcpu leaves that time unused. hw.ncpu is the right number for a compile job.
• Past 10, nothing changes. -j16 and bare -j were within a second of -j10. The cores were already full.
• The cost of bare -j is memory. Sampling ps every 0.2 s, -j10 peaked at 10 clang -cc1 processes with 3,815 MiB summed RSS. Bare -j peaked at 30 processes and 7,483 MiB. That sum double-counts shared pages, so read it as a ratio, not as an exact footprint. On a 16 GB machine, 30 targets fit. A project with a few hundred translation units, or C++ files that each take a gigabyte to compile, would not, and the build would start swapping instead of failing.

So when a missing nproc turns into bare -j, a small project shows no symptom at all. That fits what python/devguide#1545 recorded: on macOS, make -j $(nproc) printed zsh: command not found: nproc and then built CPython anyway, so the docs switched to a fixed -j8. y-scope/clp#332 had macOS CI jobs timing out "without a clear reason", with the nproc line in the log. It switched to getconf, and the next run passed.

A replacement that fails when it should

The idea is to try each source in turn, then stop if none of them returned a number, instead of passing an empty string to make:

jobs=$(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || getconf _NPROCESSORS_ONLN 2>/dev/null)
case $jobs in
  ''|*[!0-9]*) echo "could not count CPUs (got '$jobs')" >&2; exit 1 ;;
esac
make -j"$jobs"

On the stock PATH this printed make -j10 under bash, sh, and zsh. With Homebrew's nproc first and OMP_NUM_THREADS=3, it printed -j3. With an empty PATH, it exited 1 with the message instead of building. Put nproc first if you want Linux containers to respect their cgroup CPU quota. GNU nproc reads it, and getconf may report the host's count instead.

About getconf _NPROCESSORS_ONLN on its own: it works on macOS and on glibc Linux, which is why many projects switch to it. But it isn't guaranteed. POSIX.1-2024's getconf page lists the variables every getconf must support and specifically excludes _SC_NPROCESSORS_CONF and _SC_NPROCESSORS_ONLN, even though the C function sysconf() gained them in the same edition. Treat it as one more link in the chain, and keep the guard.

275 GitHub threads: what people replaced nproc with

I pulled every issue and pull request that GitHub search returns for "nproc: command not found" (bash's wording, 272 results) and "command not found: nproc" (zsh's wording, 252). Search ignores punctuation, so the two sets overlap by 247, leaving 275 unique threads. In 107 of them the exact error string is in the title or body. Of those 107, 88 mention macOS and 11 mention Windows shells. Reports are growing: 13 in 2024, 26 in 2025, and 15 so far in 2026. I left out bare-sh's nproc: not found (477 results), which is mostly Alpine and other minimal Linux images.

Counting fixes across all 275 bodies: hw.ncpu appears in 15, hw.logicalcpu in 10, getconf … NPROCESSORS_ONLN in 9, an nproc … || fallback in 4, and hw.physicalcpu in 2. perflevel0 appears in none. Nobody is limiting builds to performance cores, and given the 32% result above, that's the right call.

Two patterns kept coming up when I read them:

• The nproc line is sometimes just noise. 29 of the 275 threads are about building sentencepiece. In sentencepiece#1103, nproc: command not found sits between two cmake: command not found lines, and the build exited 127 because cmake wasn't installed. The project's build script now uses nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null || echo 4. If you see the nproc line in a failed log, check the line above it before you install coreutils.
• The flag-swallowing case is real. stressy#146 shows stressy -w $(nproc) -t 1s on macOS, where -w took -t as its argument and the tool rejected "-t" as a worker count. That's the good outcome. A tool that accepts any string as a value would have kept going with the wrong one.

This keeps happening with GNU tools that macOS lacks: the failure is quiet rather than loud. timeout command not found on Mac covers which coreutils programs macOS lacks, shuf on Mac shows the sort -R substitute grouping duplicates, and bash pipe exit code explains why a failure in the middle of a pipeline usually doesn't reach $?. The same check catches all three: run the script once with PATH=/usr/bin:/bin:/usr/sbin:/sbin before you ship it. For the BSD xargs that the -P row above runs into, see xargs on macOS.

Update, October 1, 2026: the same kind of gap hits watch, where the common while-loop replacement drifts and can ignore Ctrl-C. Measurements and a zsh fix are in watch command on Mac.

Sources: all measurements were run on 2026-10-01 on a Mac mini M4 (Mac16,10, 16 GB, macOS 26.4.1 build 25E253) with PATH pinned to the system directories: bash 3.2.57, zsh 5.9 with -f, GNU make 3.81 from the Command Line Tools, Apple clang 21.0.0, and Homebrew coreutils 9.12 for the GNU nproc comparison. The build test is 30 compiles of the SQLite 3.50.4 amalgamation, two rounds per job count plus one -j1 run. Process counts and summed RSS came from ps sampled every 0.2 s. The Makefile and scripts are kept with my research notes. The make behavior is quoted from the GNU make manual, the sysctl names from Apple's documentation, and the getconf exclusion from POSIX.1-2024. The GitHub figures come from two gh api search/issues queries run the same day (275 unique threads, complete results). The fix counts are string matches in titles and bodies, and I read the quoted threads in full.