bash-format: fallback drops --apply-ignore, bare [*] .editorconfig section treated as shell opt-in, openBinaryFile failures on Windows paths

[kyle-sexton]

Three defects observed in the bash-format plugin hook (2026-07-30, Windows host)

1. Fallback discards --apply-ignore. The hook runs shfmt --apply-ignore -w "$FILE" 2>/dev/null || shfmt -w "$FILE" 2>/dev/null. When the first call fails for any reason, the fallback re-formats WITHOUT --apply-ignore, so a repo's .editorconfig [*.sh] ignore = true is intermittently discarded and files get re-tabbed to shfmt defaults. Verified shfmt --apply-ignore -w standalone (v3.13.1) is a correct no-op with the opt-out in place — only the fallback defeats it.
2. Bare [*] section reads as a shell opt-in. shell_editorconfig_opt_in contains [[ "$h" == '*' ]] && return 0, so any repo with a generic .editorconfig (most repos) is opted into shfmt formatting regardless of intent.
3. openBinaryFile: does not exist (No such file or directory) raised intermittently by the shellcheck and typos hook invocations on Windows paths — looks like the same path-handling class.

Where observed

kyle-sexton/autonomy-demo-scratch PR #67 babysit worker run; the worker had to land its final shell file via cp because the hook kept re-tabbing it through the fallback path.

[kyle-sexton]

Triaged — defect 1 verified and fixed; defect 2 verified but needs your call; defect 3 has a different cause

Reproduced in throwaway git repos with a stub shfmt on PATH, against the shipped hook and the fix.

Defect 1 — the fallback discards --apply-ignore — VERIFIED, fixed

Scenario	shipped	with the fix
ignore = true repo, first shfmt call fails for a non-flag reason	REFORMATTED	untouched
ignore = true repo, real shfmt v3.13.1	untouched	untouched

The second row confirms your standalone finding: shfmt --apply-ignore -w is a correct no-op with the opt-out in place, so only the fallback defeats it.

Fixed by probing the flag rather than inferring its absence from a failed run: shfmt --apply-ignore --version succeeds on 3.8+ and fails on older versions, which is a capability question rather than an outcome question. || could not distinguish "this shfmt has no such flag" from "this run failed", which is exactly the confusion. Where the flag exists, a failing run now leaves the file untouched — the only safe reading of a formatter that did not complete. Old shfmt still gets the plain in-place format it always did.

Defect 2 — bare [*] reads as a shell opt-in — VERIFIED, left for a maintainer decision

Reproduced: a repo whose .editorconfig contains only

root = true
[*]
end_of_line = lf
insert_final_newline = true

has its shell files reformatted to shfmt defaults. Control: an explicit [*.sh] section also opts in, as intended.

Not fixed here, deliberately. This is documented, deliberate behaviour, not an oversight — section_applies_to_shell carries [[ "$h" == '*' ]] && return 0 under a comment explaining the catch-all case, and EditorConfig semantics agree that [*] governs shell files. But the same function's comment states the opposite intent for the outcome you hit: "a repo whose .editorconfig only configures other languages must not have its shell files rewritten to shfmt's built-in defaults." A [*] section setting only end_of_line and insert_final_newline is exactly that case, and it currently triggers a full re-indent.

So the design and its stated rationale disagree, and resolving that changes formatting behaviour for every consumer with a generic .editorconfig — in the safe direction (format less), but still a behaviour change that some repos may be relying on. That is a maintainer's call rather than mine.

If it helps, the option I would recommend: treat [*] as a shell opt-in only when it carries a property shfmt actually honors — indent_style or indent_size. A [*] that expresses an indentation intent is a repo asking for consistent indentation including shell; a [*] that sets only line endings or charset is not, and today it gets shfmt's defaults imposed anyway. That keeps the catch-all working where it was meant to and closes the case you hit, without requiring an explicit [*.sh] section.

Defect 3 — openBinaryFile: does not exist — NOT reproducible here, and the diagnosis is different

This is not a path-handling failure. openBinaryFile: does not exist (No such file or directory) is ShellCheck's (GHC's) error for a path that does not exist, and it reproduces on demand:

$ shellcheck D:/nope/missing.sh
D:/nope/missing.sh: D:/nope/missing.sh: openBinaryFile: does not exist (No such file or directory)

Path form is not the trigger on this host — both an MSYS path (/d/repos/…/bash-format.sh) and a Windows path (D:/repos/…/bash-format.sh) lint cleanly through the same shellcheck build.

And bash-format already guards against a missing file: hook::read_file_path does [[ -f "$file" ]] || return 1, and the hook exits 0 on that. Driving the hook with a file_path that does not exist produces no output at all — no error, no findings. The same hook-utils.sh (with the same guard) is shared by typos-format, markdown-format, biome-format, and eol-normalizer, so none of them can surface this from a file that is already gone when the hook starts.

What that leaves, and what I could not confirm without the original session: a genuine race — the file exists when the guard runs and is gone by the time shellcheck/shfmt is invoked a few lines later. That is plausible in a babysit-worker run where a worktree is cleaned or a scratch file removed mid-flight, and it matches "intermittent". Closing that window is a two-line re-check immediately before the tool invocations, but I have not shipped it: I could not reproduce the failure, and hardening a hot path against an unconfirmed race is a guess.

If you can still reach that session's logs, the useful detail is whether the failing path was ever real — if it was a file the worker deleted, the race is confirmed and the re-check is the fix.

PR scope

Defect 1 only. Defect 2 is verified and left open above with a recommendation; defect 3 is unverified against this plugin with the diagnosis corrected. Suite: 43 assertions, 0 failures — one new case pinning that a failed --apply-ignore run does not re-format without the flag, alongside the existing shfmt<3.8 fallback case, which still passes unchanged because a stub that rejects the flag also fails the probe.