From: Max Vilimpoc <max@vilimpoc.org>
Date: Sun, 6 Sep 2026 15:44:24 +0000 (+0200)
Subject: dotfiles: stop the ssh.exe check from deleting the ssh.exe it verifies
X-Git-Url: https://vilimpoc.org/repos/dotfiles/commitdiff_plain/4658d6ddc8aaaa7e6b52fe3939151d3b35ddacab?hp=4658d6ddc8aaaa7e6b52fe3939151d3b35ddacab

dotfiles: stop the ssh.exe check from deleting the ssh.exe it verifies

The rsync step's run-it-to-verify check has been throwing away a working
ssh.exe on almost every run since it was added, on every architecture:

    try { $sshVer = (& $SshExe -V 2>&1 | Select-Object -First 1) } catch { }

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
---