Module posix_shell 

Locate the POSIX sh that shellexec (the !cmd composer prefix) runs its one-shot sh -c commands under.

On Unix this is just sh. On Windows it was also just sh, which only resolves when srv’s PATH happens to contain a Git Bash tool directory — true for a dev build started from a Git Bash terminal, false for an installed/portable build started from Explorer. Git for Windows’ installer puts only Git\cmd on the system PATH by default, and that directory has git.exe but no sh.exe, so every !cmd failed with shellexec: spawn failed: program not found.

Two traps shape the Windows search order:

• Git\usr\bin\sh.exe (the real binary) cannot run ls unless its own directory is already on PATH. Git\bin\sh.exe is Git’s launcher: it prepends /mingw64/bin:/usr/bin itself, so the fallbacks below point at bin\sh.exe, never usr\bin\sh.exe.
• C:\Windows\System32\bash.exe is WSL. A PATH search for bash would run !cmd inside a Linux VM with different paths, so the PATH search looks for sh.exe only (WSL ships no sh.exe).

Constants

SHELL_OVERRIDE_ENV

Explicit override: a path to a bash/sh executable. Same variable agentmux-bashwrap honours for its own bash lookup.

Functions

git_launcher 🔒

Git for Windows’ sh launcher under an install root.

is_windows_absolute 🔒

C:\… / \\server\…. Checked by hand rather than Path::is_absolute so the rule is the same when the tests run on a Unix CI host. A bare \foo is drive-relative on Windows, so it doesn’t count.

resolve_posix_shell

Resolve the program shellexec should spawn as <program> -c <cmd>.

resolve_windows 🔒

Windows search order, first hit wins: