fix(make): drop xargs -r so make lint runs on BSD xargs (backend#2200)

[aptracebloc]

Closes tracebloc/backend#2200

Problem

client/Makefile's parse, shellcheck and lint-warnings recipes pass xargs -0 -r. GNU xargs accepts -r; older BSD/macOS xargs rejects it outright (xargs: illegal option -- r), so make lint dies at the very first recipe on macOS — the platform the surrounding arch work targets.

(Current macOS shipped a no-op -r GNU-compat shim, so the break only reproduces on older boxes — but the flag is still non-portable, and CI/dev machines shouldn't depend on which macOS you're on.)

Fix

Drop -r from all three recipes. -r only suppresses xargs' single run on empty input, and every recipe already refuses empty input upstream:

• parse exits on its explicit zero-count guard before reaching xargs;
• shellcheck/lint-warnings bail when sh-files.sh exits non-zero on a zero-file classification.

So xargs always receives ≥1 item and -r was dead code on GNU too — removing it is behaviour-preserving on Linux/CI and fixes older BSD/macOS. The recipe comments already describe the loop as xargs -0 -n1 (no -r), so this also restores code/comment agreement.

Fixed all three occurrences, not just the two named in the ticket — lint-warnings carried the same flag and the same bug (fix the class, not the instance).

Verification

Run on macOS 26.3.1 (Darwin 25.3.0), genuine BSD /usr/bin/xargs, shellcheck 0.11.0:

Scenario	Result
make lint on this box (BSD xargs)	✅ 63 scripts parse, 70 shellchecked, rc=0
Old Makefile (-r) under a -r-rejecting xargs shim (old macOS)	❌ make: *** [parse] Error 1 — reproduces #2200
New Makefile (no -r) under the same shim	✅ rc=0 — fix confirmed
Empty/failed classifier (real sh-files.sh path)	✅ guard bails before xargs

Linux/GNU is exercised by the required Lint check on ubuntu-latest here.

---

Note

Low Risk
Makefile-only portability tweak to lint recipes; no runtime, auth, or data-path changes, with empty-input behavior already guarded upstream.

Overview
Fixes make lint on BSD/macOS where xargs rejects the GNU-only -r flag (xargs: illegal option -- r), which blocked parse and everything downstream on older macOS dev boxes.

The parse, shellcheck, and lint-warnings recipes now use xargs -0 instead of xargs -0 -r. Removing -r is intended to be behavior-preserving: each recipe already fails closed before xargs when there are zero files or classification fails, so xargs always gets at least one path. This also aligns the commands with existing comments that describe xargs -0 -n1 without -r.

^{Reviewed by Cursor Bugbot for commit 655cabf. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saqlainsyed007]

Reviewed at 655cabf. Correct and safe — no findings; holding only on CI (PENDING).

Dropping xargs -r (a GNU-only --no-run-if-empty, absent on BSD/macOS xargs) is a pure portability fix here, and I checked the one thing that could bite — behavior on an EMPTY file list, since without -r xargs would otherwise run the command once with no operands. It can't reach that state in any of the three targets: sh-files.sh exits non-zero on a zero-file classification (per the SH_FILES comment), and shellcheck/lint-warnings both gate on if ! $(SH_FILES) …; then exit 1; fi before the xargs line, while parse has its own explicit ZERO-refusal (found ZERO shell scripts … exit 1). So the list is always non-empty by the time xargs runs — the -r was redundant and removing it changes nothing but the BSD breakage. -0 is retained, so NUL-delimited paths are still safe.

Once CI is green I'll approve on the next pass.

[aptracebloc]

CI is green now — all required checks pass (Lint, quality/shellcheck, closing-ref, version-bump-gate) and Bugbot is clean. Re-requesting your review per your note. Thanks for the independent empty-input check — matches the guard analysis exactly.

[saqlainsyed007]

Approving at 655cabf — CI is green now, which was the only thing I was holding on.

Verified last pass: dropping the GNU-only xargs -r is a pure BSD/macOS portability fix, and the empty-input case it guarded can't be reached — sh-files.sh exits non-zero on a zero-file classification and all three targets gate on if ! $(SH_FILES) …; then exit 1; fi (parse also has its own ZERO-refusal) before the xargs line, with -0 retained. No behaviour change, no findings, no threads, mergeable. LGTM.