docs: fix windows powershell install command

[justinwlin]

Closes #311

Context

The README's Windows install snippet was copied from the Linux one:

wget https://github.com/.../runpodctl-windows-amd64.exe -O runpodctl.exe

On Linux, wget is a download tool and -O means "save as this filename."

The issue

On Windows, wget is not that tool. PowerShell aliases wget to its own Invoke-WebRequest, which has no -O parameter. PowerShell allows abbreviated parameter names only when unambiguous, and -O matches four (-OutFile, -OutVariable, -OutBuffer, -OperationTimeoutSeconds), so it refuses:

Parameter cannot be processed because the parameter name 'O' is ambiguous.

Nothing downloads. The documented Windows install path has been broken since January 2024 (3da74ab).

A second, older problem showed up while fixing it: even when the download worked, it dropped a bare exe into the current directory with no PATH entry. macOS and Linux users get a working runpodctl command; Windows users had to cd to that folder and type .\runpodctl.exe.

The fix

• Use Invoke-WebRequest with the full -OutFile name. Correct on Windows PowerShell 5.1, and on PowerShell 6+ where the wget alias no longer exists at all.
• Install properly: download the zip, expand to %LOCALAPPDATA%\runpodctl, add that to the user PATH. runpodctl then works from any terminal.
• Document the amd64→arm64 swap, and the "open a new terminal" step.
• Link docs.runpod.io/runpodctl/overview as the canonical install guide, so the README is not the thing that silently drifts.

One deliberate difference from the skills-repo guide

The zip-plus-PATH approach is taken from the install guide in the runpod skills repo, but the PATH handling here intentionally differs. That guide does:

[Environment]::SetEnvironmentVariable('Path', $env:Path + ";$env:LOCALAPPDATA\runpodctl", 'User')

$env:Path is the process PATH, which already contains the machine entries. Writing it back into the User variable copies the system PATH into it permanently, and appends a duplicate on every re-run. This PR reads the User PATH directly and guards with -notlike.

-UseBasicParsing is defensive only: Invoke-WebRequest on Windows PowerShell 5.1 can fail with "the Internet Explorer engine is not available…" on fresh installs and Server Core. I have not reproduced that failure, and it may not apply when -OutFile is used. The switch is a no-op on PowerShell 6+, so it costs nothing either way.

Verification

• Downloaded and listed both runpodctl-windows-amd64.zip and runpodctl-windows-arm64.zip: each contains runpodctl.exe at the root, so -DestinationPath and the PATH entry are correct and the documented arm64 swap works.
• The asset URL returns 200.

Not verified on Windows. No Windows machine or CI runner is available, and the bug only reproduces on Windows PowerShell 5.1 where the wget alias exists. The above is artifact inspection and reasoning, not execution — please paste the snippet into a Windows terminal once before merging.

---

Related PRs

Two independent groups. Nothing in one blocks anything in the other.

Group A — the Windows install command (#311)

One broken command that had been copy-pasted into three repos. Each PR fixes its own copy; any order, no dependencies.

PR	Repo	Change
#328 ← this PR	runpodctl	README.md — fix the command, and install to PATH
runpod/docs#805	docs	runpodctl/overview.mdx — same fix on docs.runpod.io
runpod/runpod-plugins-official#49	plugins	delete reference/install.md, the third copy

Group B — secure registry passwords (#327)

Order matters. #51 documents a flag that does not exist on main until #329 merges, so it stays draft until then.

#	PR	Repo	Change
1	#329	runpodctl	--password-stdin, no-echo prompt, mutually exclusive flags
2	runpod/runpod-plugins-official#51	plugins	skill guidance + regression eval (draft until #329 lands)

The only thing the two groups share is that both touched the runpodctl skill, which is what prompted Group A's deletion: the skill had been keeping its own copy of install instructions the runpodctl README already owned.

[lukepiette]

Could we compare complete PATH entries rather than using a wildcard substring? $userPath -notlike "*$dest*" treats a path such as ...\runpodctl-old as though $dest is already installed, and wildcard characters in the expanded path are interpreted as pattern syntax. A missing User PATH also produces a leading empty entry.

Splitting on ;, dropping empty entries, and using -notcontains $dest avoids all three cases:

$userPath = [Environment]::GetEnvironmentVariable('Path', 'User')
$pathEntries = @($userPath -split ';' | Where-Object { $_ })
if ($pathEntries -notcontains $dest) {
  [Environment]::SetEnvironmentVariable(
    'Path',
    (($pathEntries + $dest) -join ';'),
    'User'
  )
}

[lukepiette]

Approving. The PATH-entry comment is a non-blocking robustness improvement.