Windows agent shells: Git Bash bash.exe versus WSL bash, and multi-line python -c failing through the bash shim

Two separate observations from agent sessions on Windows. Neither was reproduced in a controlled test here; both come from recorded failures and the fixes that worked at the time. Versions were not recorded.

For the related traps of MSYS path conversion when a native program receives a Unix-style argument (for example flyctl remote paths, or an Android /sdcard path given to adb), see the separate articles on those tools; the mechanism is the same.

Which bash runs a script: WSL bash versus Git Bash

A shell script that was meant to run under Git Bash was launched with the bash that resolves first on that machine. Two failures were recorded:

execvpe(/bin/bash) failed

and, from a Git Bash run given a Windows-style path:

Cannot connect to C

The source attributes the first message to WSL and does not explain it; whether a Linux distribution was installed there is not recorded. It also does not say which tool printed the second message or why. Both causes are therefore unknown, and only the fix below is observed.

What worked: calling the Git installation's shell by full path and giving the script MSYS-style paths:

"C:\Program Files\Git\bin\bash.exe" ./package-site.sh /c/path/to/output

(package-site.sh stands for the packaging script of the original task; the argument shown is illustrative.) The two parts of the fix go together: the Git bash is chosen explicitly so that the first bash on PATH is not WSL's, and paths use the /c/... form that this shell understands.

Multi-line python -c through the bash shim

On one Windows setup the bash command run by an agent tool was a shim. When a multi-line python -c "..." string was sent through it, the content was sometimes routed through PowerShell, which then parsed Python keywords as PowerShell syntax:

The 'from' keyword is not supported in this version of the language.

The same pattern with import was listed as likely to fail the same way. The word "sometimes" is the source's own: the routing was not traced, and which inputs triggered it was not established. Observed as unaffected:

• single-line python -c "..." commands (one verification used python -c "import os; t=os.environ.get(...); print(...)" and ran);
• running a .py file.

The fix that was applied: put the logic in a .py file (a verification script in the project's scripts folder) and run that file instead of passing multi-line code on the command line. The behaviour was recorded against the Windows bash shim of an agent harness, so it may not apply to a plain Git Bash terminal, which was not tested for it.