fix(install.ps1): WSL detection — strip null bytes from UTF-16 wsl --list output#1005
Merged
Merged
Conversation
…regex Caught during Carl-OOTB Windows validation (continuum-b69f, 2026-05-02). Symptom: fresh Windows validator with Ubuntu running in WSL2 sees: + Git for Windows already installed + Docker Desktop already installed -> Installing WSL2 + Ubuntu (will require admin elevation + a reboot on first install) ... ! Not running as admin. WSL2 install needs admin -- relaunch ... The 'Installing WSL2' branch fires falsely; install.ps1 thinks Ubuntu isn't there. But `wsl.exe --list --verbose` clearly shows Ubuntu Running. Cause: wsl.exe writes --list output as UTF-16 LE (each char is two bytes, the 'real' byte plus a null). PowerShell reads it as UTF-8, so each distro name lands as "U`0b`0u`0n`0t`0u`0" instead of "Ubuntu". The regex `-match 'Ubuntu'` never matches across null-interleaved chars. Verified the byte pattern locally: > $d = & wsl.exe --list --quiet > $d[0] # 'U b u n t u ' ← spaces are nulls in display > [byte[]][char[]]$d[0] # 85,0,98,0,117,0,110,0,116,0,117,0 Fix: strip nulls from wsl output before pattern-matching: $distros = (& wsl.exe --list --quiet 2>$null) -replace "`0", "" One-line change. 8 lines added (with the comment explaining why so the next person doesn't reintroduce the bug). Behavior on machines without Ubuntu installed is unchanged — the regex falls through, Install-WSL2 flow continues to the admin-prompt path correctly.
This was referenced May 2, 2026
Open
joelteply
added a commit
that referenced
this pull request
May 2, 2026
#1010) When WSL2 has lost external network reachability (vEthernet / HNS corruption is common on Win10/11 after sleep cycles, driver updates, or system patches), the curl inside `bootstrap.sh | bash` takes 30+ seconds to time out with a cryptic error — and the user has no signal that the issue is environmental, not continuum-related. Caught live 2026-05-02 by continuum-b69f during Carl-OOTB Windows testing (issue #1006). After PR #1005 fixed the WSL detection bug, install.ps1 delegated into bootstrap.sh successfully — and the WSL- side curl just hung. The user has no way to tell whether the install is broken or their box's WSL is broken. Fix: 5s curl probe to raw.githubusercontent.com from inside WSL BEFORE the delegate. If it fails, surface explicit Windows-side remediation: 1. wsl --shutdown 2. (as admin) Restart-Service hns -Force 3. Reboot Windows 4. Edit %USERPROFILE%\.wslconfig — networkingMode=NAT + Re-run command Pattern: same family as install.sh's friendly-failure phase traps (#977 work) — fail loudly and tell the user exactly what to try NEXT, instead of dying silent or with a 30s mystery timeout. ## Tests - Edit-only PowerShell change, no shape change to delegate path when probe passes. - Linux/Mac CI not affected (probe block is inside install.ps1). - Live validation pending b69f's box (currently the WSL2 NAT is broken on their box per #1006 — perfect natural test case for the new probe message). Co-authored-by: Test <test@test.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Carl-OOTB Windows blocker — phase 1 (prereqs)
Discovered during continuum-b69f's Carl-OOTB Windows validation 2026-05-02. Fresh-Windows validator with Ubuntu installed and running in WSL2 hits:
But
wsl --list --verboseshows Ubuntu running. TheInstall-WSL2detection in install.ps1 thinks WSL is missing and demands admin elevation.Root cause
wsl.exe --list --quietwrites UTF-16 LE. PowerShell reads stdout as UTF-8, so each distro name interleaves with null bytes:The detection's regex
-match 'Ubuntu'never fires.Fix
One line: strip nulls before regex.
Plus a comment block so the next reader doesn't reintroduce the bug — matches the local convention (PR #265 / #394 / #396 all carry similar 'caught by X on date Y' notes).
Test plan
+ WSL2 + Ubuntu already installednow fires correctly, install proceeds past Phase 1 prereqs.Why this matters
Every Windows user running
irm install.ps1 | iexafter this PR lands gets past Phase 1 instead of hitting a wall on a working WSL install. The detection is a one-line bug masking a working environment.🤖 Generated with Claude Code