fix(cua-driver)(#1651): install.ps1 updates current shell's PATH for immediate cua-driver resolution - #1652
Conversation
… so cua-driver resolves immediately
User-facing bug: after `irm install.ps1 | iex`, `cua-driver --version`
fails with "not recognized" in the SAME shell. The installer wrote the
bin dir to the User PATH registry, but PowerShell's $env:Path was
cached at process start — the registry update doesn't propagate to the
running shell. The post-install message even acknowledged this:
cua-driver will resolve in any NEW PowerShell window.
In THIS shell, invoke via the full Binary path printed below.
That's a usability papercut. The user just ran the install one-liner,
sees "0.2.16 installed", and their natural next command fails. They
either re-read the message and copy the full binary path, or open a
new tab. Either way: the install LOOKS broken.
## Fix
install.ps1 runs in the caller's PowerShell via `iex` (per the
`irm install.ps1 | iex` one-liner), so it CAN mutate that shell's
$env:Path directly. Add-UserPathEntry now does two writes:
1. Persistent (registry, via Environment::SetEnvironmentVariable
scope=User) — unchanged.
2. Current process ($env:Path prepend, idempotent) — new.
The current-process write is guarded with a `-contains` check so
re-running the installer doesn't accumulate duplicate entries.
Plus updated the post-install hint and the manual-PATH-instructions
helper to say "resolves immediately in this shell" instead of "in any
NEW PowerShell window".
## Verification
```powershell
PS> irm install.ps1 | iex
...
Added C:\Users\cuademo\AppData\Local\Programs\Cua\cua-driver\bin to your User PATH.
cua-driver resolves immediately in THIS shell and in any new shell.
PS> cua-driver --version
cua-driver 0.2.17 # ← was: "not recognized" before this fix
```
Closes #1651.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe installer updates the current PowerShell session's ChangesInstall Session PATH Availability
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The previous params conflicted in meaning with install.ps1: - install.ps1's `-Release "<version>"` selects the release TAG to install - install-local.ps1's `-Release` switched build CONFIGURATION (debug vs release) Both were named `-Release` but meant entirely different things. Confusing for anyone bouncing between the two scripts. Aligning install-local.ps1's surface with install.ps1: - Drop `-Release` switch entirely. Always build in release mode (matches what install.ps1 hands end users — the GitHub Releases zip is built --release). If a dev wants debug builds for faster compile iteration, invoke `cargo build -p cua-driver` directly and use the resulting target\debug\cua-driver.exe themselves. - Add `-NoPathUpdate` switch + the corresponding PATH-update step that install.ps1 has. Also updates $env:Path in the current shell so cua-driver resolves immediately (matches #1651 / PR #1652 behavior). - Keep `-AutoStart` — same shape as install.ps1. Final params: `-AutoStart`, `-NoPathUpdate`. Exact subset of install.ps1. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…surface + v0.2.14+ paths (#1655) Dev-script polish so the local-build install loop matches what end users experience. Two changes: 1. **Path defaults**: switch the visible bin dir and package home defaults to v0.2.14+ layout (`Programs\Cua\cua-driver` + `~/.cua-driver`). Previously install-local.ps1 was still using the legacy `trycua\cua-driver-rs` paths, which meant local-build installs landed in a different location than what install.ps1 produces — and the `current` junction couldn't flip between them. 2. **Param surface mirrors install.ps1**: drop the `-Release` switch (which conflicted in meaning with install.ps1's `-Release "<version>"` tag selector — confusing for anyone bouncing between the two scripts) and always build release-mode (matches what install.ps1 hands users — the GitHub Releases zip is `--release`). Add `-NoPathUpdate` switch + corresponding User-PATH update step (also writes $env:Path in the current shell so cua-driver resolves immediately, matching PR #1652 / #1651's behavior). Keep `-AutoStart` as-is. Final param surface: `-AutoStart`, `-NoPathUpdate` — exact subset of install.ps1's user-facing params. If a dev wants a debug build for faster compile iteration, invoke `cargo build -p cua-driver` and use target\debug\cua-driver.exe directly. Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Summary
After `irm install.ps1 | iex`, the user's next `cua-driver --version` fails with "not recognized" because PowerShell's `$env:Path` was cached at process start and doesn't see the User PATH registry update. install.ps1 runs in the caller's shell via `iex`, so it CAN mutate `$env:Path` directly. This PR makes `Add-UserPathEntry` do that too.
Fix
Two-line change in `Add-UserPathEntry`:
```powershell
if (-not (($env:Path -split ';') -contains $dir)) {
$env:Path = "$dir;$env:Path"
}
```
Plus hint-message update: "resolves immediately in THIS shell and in any new shell."
Verification
Before:
```
PS> irm install.ps1 | iex
... cua-driver-rs 0.2.16 installed.
PS> cua-driver --version
cua-driver : The term 'cua-driver' is not recognized ...
```
After (v0.2.17):
```
PS> irm install.ps1 | iex
... cua-driver-rs 0.2.17 installed.
PS> cua-driver --version
cua-driver 0.2.17
```
Closes #1651.
🤖 Generated with Claude Code
Summary by CodeRabbit
cua-driverwithout restarting your terminal.cua-driveris available immediately in the current session.