Under macOS's bash 3.2, a failing command <utility> in a list or an if condition exits a set -e script: lanes --worktrees dies silently (lanes:317), and wip's .gitignore step can stop (openRepoTools:4014) #292

Found by lane openRepoTools-4's independent delta review of #289 (its SHOULD-B). The coordinator confirmed it on GNU bash 3.2.57, a musl build of the same source as macOS's /bin/bash. Nobody has run it on a Mac yet.

The quirk

Under set -e, bash 3.2.57 exits when a command run through the command builtin fails, even in the places where set -e must be ignored:

• on the left of || or &&;
• after !;
• in an if condition;
• inside a function called from any of those.

bash 5.2.21 carries on in every one of these cases.

Each line below was run as bash -c 'set -e; <shape>; echo ok':

• command false || :: 3.2 exits 1, 5.2 prints ok.
• command grep -q x /dev/null || :: 3.2 exits 1, 5.2 prints ok.
• if command grep -q x /dev/null; then :; fi: 3.2 exits 1, 5.2 prints ok.
• ! command false, command false && :, command test -e /nonexistent || : and command cd /nonexistent || : behave the same way.
• These are not affected:
  • plain if grep -q x /dev/null; then :; fi, with no command;
  • command -v nonexistent || :, and if command -v …;
  • printf '' | command grep -q x || :, inside a pipeline;
  • x=$(command false) || :.

Where it bites on main (a42946e)

Both scripts run under set -euo pipefail.

1. lanes:317, in lanes --worktrees: command grep -v -e 'not fetching; reading origin/' "$wt_err_file" >&2 || :.
   • When the helper's stderr holds only the "not fetching" line, grep -v selects nothing and exits 1. lanes then exits 1 with no output at all.
   • The line came in with f5444c5.
   • The same file's other filter (lanes:531) uses plain grep and is not affected.
2. openRepoTools:4014, in wip_hygiene_lines: command grep -Fqx -- "$line" "$1" 2>/dev/null || missing=….
   • The grep fails exactly when a hygiene line is missing from the .gitignore. Under 3.2 the script exits there instead of collecting the line.
   • The function's caller (:3987) puts it on the left of ||, but that does not help: the same shape, run in isolation under 3.2.57, exits 1, and under 5.2.21 it finishes.

Not affected:

• lanes:503 and :507 run command grep inside a pipeline.
• lanes-edit.sh has command grep in lists too, but it runs without set -e.

Effect

• On macOS, lanes --worktrees can print nothing and exit 1.
• openRepoTools wip init can stop part-way through writing a template's .gitignore.
• CI runs only Linux with bash 5.2, so it cannot see either. A lane listing that is not whole no longer removes indexed worktree rows: the inventory read says PARTIAL, lanes --worktrees prints it NOT WHOLE, and lanes-index writes nothing over it; an older helper's tree with no path stays a tree (#173 item c1, #252 delta review 2) #289's four tests of lanes --worktrees for lanes-index inventory follow-ups from Copilot rounds 3 and 4 on #171: unread-lane answers, partial listings, foreign-source marks, SQLite read errors, footer remedy #173 item c1 fail under bash 3.2.57 because of lanes:317 alone. With that one word dropped, they pass under 3.2.57.

Fix

• Drop the word command at the two sites, as the rest of lanes already does, or test the exit status explicitly.
• A hygiene test could keep the shape from coming back. It would grep the set -e scripts for command <utility> used in a list, after !, or in an if condition, excluding command -v.

Ownership

This bug predates #289 and is outside lane 4's assignment (#90 to #194). Lane 4 has not claimed it; it is filed for whoever Brett Heap names, since the lane tooling is lane 3's.

Lane: openRepoTools-4