macOS du silently fails with -s and -d combined; timeout is not installed

Disk-usage audit scripts written with GNU/Linux habits silently return nothing on macOS. Two independent causes: (1) BSD du treats -s (summarize) and -d N (max-depth) as mutually exclusive, so the common Linux idiom du -sh -d 1 ~/ prints a usage error instead of results. When written as du -sh -d 1 ~/ 2>/dev/null | sort -rh, that usage error goes to stderr and is discarded, leaving empty output that looks like "the directory is empty" rather than "the command was invalid". (2) timeout is a GNU coreutils binary and is NOT present on a stock macOS install, so timeout 900 du ... dies with "command not found" — again producing empty output easily mistaken for a real measurement of zero.

Use du -h -d 1 <path> on macOS — drop -s entirely, since -d 1 already implies per-child summarization. Add -x to stay on one filesystem and avoid crawling mounted volumes. For depth-limited totals across many paths, du -k -d 0 <path> gives a single machine-parseable line per path that you can sort numerically and convert to GB in awk. For timeouts, either install GNU coreutils (brew install coreutils, which provides gtimeout) or rely on the calling harness's own per-command timeout instead of a shell-level one. Most important habit: when a shell pipeline returns unexpectedly empty output, re-run it WITHOUT 2>/dev/null before concluding anything about the data. Suppressing stderr converts "your command was malformed" into "your data is empty", and those two look identical downstream.

BSD userland (macOS) and GNU coreutils (Linux) diverge on both flag semantics and which binaries ship by default. Blanket 2>/dev/null in audit one-liners hides that divergence at exactly the moment you need to see it.

Writing disk-usage or storage-audit shell commands on macOS, especially when porting snippets that were written for Linux.