Select-Object stops the pipeline the instant it has its one object, and
that is when ssh.exe has WRITTEN its banner - not when it has exited.
PowerShell then tears the pipeline down, kills the still-running process,
and reports -1. Measured on a healthy binary on the x64 box: 24 of 25 runs
reported exit -1 through Select-Object, 25 of 25 reported 0 when the output
was collected first. So collect, then take the first line.
The bug hid behind its own warning. A killed process looks exactly like the
failure the check exists to catch, the warning names the release's ssh.exe
rather than the test, and the resulting fallback to the in-box client - the
~17MB/s one this whole step exists to avoid - reads as a property of the
release. This box had been running on the slow client with core.sshCommand
pointed at System32 because of it. It also made the check's stated purpose
untestable: it fired whether or not the libcrypto mismatch it was written
for was present.
Verified by re-running the elevated half: ssh.exe now survives and the
per-user half repoints core.sshCommand at C:/Tools/rsync/ssh.exe.
Also teach the architecture audit where NASM actually lands. Its installer
falls back to %LOCALAPPDATA%\bin\NASM when it cannot write to Program Files
- already documented in setup-windows.bat, but never taught to the audit -
so a present, native nasm.exe reported "- not installed" while the run
still concluded that everything had resolved. winget cannot see it there
either, which is the same reason it re-downloads and re-runs that installer
on every single run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K4qCpesQL1UwJxgQy77ttG