fix windows PATHEXT resolution for .cmd/.bat wrappers by F0rty-Tw0 · Pull Request #269 · rtk-ai/rtk

F0rty-Tw0 · 2026-02-26T13:46:05Z

What changed

Added which crate to resolve binary paths with proper PATH+PATHEXT handling before spawning
New resolve_binary(), resolved_command(), and tool_exists() helpers in src/utils.rs
Replaced Command::new(...) with resolved_command(...) across all 16+ command modules (vitest, eslint, tsc, pnpm, playwright, prisma, next, pip, pytest, ruff, golangci-lint, etc.)
Removed duplicate which_command() / tool_exists() helpers from individual modules (pip_cmd.rs, pytest_cmd.rs, ccusage.rs)
Added 213 lines of tests including Windows-specific .CMD/.BAT wrapper resolution
Added troubleshooting guide for Windows "program not found" errors
Translated French comments to English in utils.rs

Impact on existing code

Every command module that spawns an external tool now goes through resolved_command() instead of raw Command::new(). On non-Windows this resolves to the same binary path, so behavior is unchanged. On Windows, .CMD/.BAT/.PS1 shims installed by npm/pnpm are now found correctly.
The which crate adds three small transitive dependencies (env_home, winsafe, rustix — rustix was already present).
Modules that had their own which_command() helpers (pip, pytest, ccusage) now use the shared tool_exists() from utils, removing ~40 lines of duplicated code.

Test plan

On Windows: run rtk vitest run, rtk lint src/, rtk tsc with Node.js tools installed via pnpm/npm — should no longer fail with "program not found"
On macOS/Linux: run cargo test --all to confirm no regressions
Verify resolve_binary("cargo") returns a valid path in CI across all platforms

Closes #212

pszymkowiak · 2026-03-02T08:00:37Z

Hi, this PR has conflicts with master. Could you rebase on current master? Thanks!

F0rty-Tw0 · 2026-03-02T10:19:50Z

Hi, this PR has conflicts with master. Could you rebase on current master? Thanks!

Should be done, plus updated the new commands with the utils.

FlorianBruniaux · 2026-03-05T19:52:32Z

Hi @F0rty-Tw0, the approach is correct and the 28-file scope is justified given the goal. Centralizing binary resolution into resolved_command() is the right call and the fallback ensures nothing breaks on macOS/Linux.

Two things before we can merge:

In release mode, if which fails to find the binary, resolved_command() silently falls back to Command::new(name), which is the original broken behavior. The warning is only emitted in debug builds. Consider making it unconditional on Windows at least, so users have a signal when the .cmd wrapper isn't being found.
init.rs shows up in the changed files but a PATHEXT fix doesn't obviously need to touch it. Could you clarify what changed there? If it's unrelated, a separate PR would keep the diff reviewable.

The tool_exists() helper, the removal of duplicated which calls across modules, and the troubleshooting doc addition are all good.

1. Remove `assert!` and `expect` when parsing action count. By default we only use the first action count found. Also add debug prints for weird cases. 2. Use `resolved_command` in rtk-ai#269 3. Return `Result` from all filter functions, and fall back to printing raw output if there is an error Other changes: 1. Add `run_bazel_filtered<F>` generic function to match Cargo and reduce code reuse 2. Merge stdout and stderr in `filter_bazel_query` (should probably refactor `bazel query` some more)

pszymkowiak · 2026-03-06T09:03:38Z

Review: LGTM ✅ — needs rebase

Verified locally — cargo fmt clean, cargo clippy clean, 506/506 tests pass (1 pre-existing failure unrelated to this PR).

Clean approach:

resolved_command() as a drop-in Command::new() replacement with graceful fallback
Proper Windows PATHEXT handling via which crate
Good test coverage including #[cfg(target_os = "windows")] tests with temp .cmd wrappers
Removes duplicated which_command() / tool_exists() helpers from pip/pytest/ccusage

Action needed: Rebase on master — conflicts in Cargo.lock and Cargo.toml (version/dependency updates, should be trivial to resolve).

git fetch origin master
git rebase origin/master

Resolve Cargo.toml conflict (keep both: your `which = "8"` + upstream version bump)

Regenerate Cargo.lock with `cargo update`

git push --force-with-lease

F0rty-Tw0 · 2026-03-06T11:17:45Z

Hi @F0rty-Tw0, the approach is correct and the 28-file scope is justified given the goal. Centralizing binary resolution into resolved_command() is the right call and the fallback ensures nothing breaks on macOS/Linux.

Two things before we can merge:

In release mode, if which fails to find the binary, resolved_command() silently falls back to Command::new(name), which is the original broken behavior. The warning is only emitted in debug builds. Consider making it unconditional on Windows at least, so users have a signal when the .cmd wrapper isn't being found.

init.rs shows up in the changed files but a PATHEXT fix doesn't obviously need to touch it. Could you clarify what changed there? If it's unrelated, a separate PR would keep the diff reviewable.

The tool_exists() helper, the removal of duplicated which calls across modules, and the troubleshooting doc addition are all good.

Should all be set, please check.
Some formatting happened in init.rs - fixed

@pszymkowiak - done

1. Remove `assert!` and `expect` when parsing action count. By default we only use the first action count found. Also add debug prints for weird cases. 2. Use `resolved_command` in rtk-ai#269 3. Return `Result` from all filter functions, and fall back to printing raw output if there is an error Other changes: 1. Add `run_bazel_filtered<F>` generic function to match Cargo and reduce code reuse 2. Merge stdout and stderr in `filter_bazel_query` (should probably refactor `bazel query` some more)

DylanDelobel · 2026-03-09T03:04:25Z

Tried the build with cargo install --git https://github.com/F0rty-Tw0/rtk --branch bug/212/cant-resolve-cmd-bat-wrappers

Working nicely for me 🎉

pszymkowiak · 2026-03-11T08:45:03Z

Hey @F0rty-Tw0, sorry for the confusion — there was a duplicate PR (#492) opened for the same fix. With so many PRs in flight right now, things got mixed up. Your PR was here first and already LGTM'd, so we're going with yours.

Could you rebase on develop (our new integration branch) so we can merge? Thanks for your patience and great work on this!

F0rty-Tw0 · 2026-03-11T09:40:14Z

@pszymkowiak no problem at all.

I'm on it today.

F0rty-Tw0 · 2026-03-11T11:00:24Z

@pszymkowiak we should be set now. Let me know if anything else is missing.

- add PATHEXT-aware command resolution via which\n- migrate affected command runners to resolved_command\n- add regression coverage for wrapper/fallback behavior

F0rty-Tw0 force-pushed the bug/212/cant-resolve-cmd-bat-wrappers branch from de135a4 to a5eea5a Compare March 2, 2026 09:40

F0rty-Tw0 force-pushed the bug/212/cant-resolve-cmd-bat-wrappers branch from fbf2bec to 6a4b6f0 Compare March 4, 2026 13:57

FlorianBruniaux mentioned this pull request Mar 5, 2026

feat: add bazel support #308

Open

pszymkowiak added the awaiting-changes label Mar 6, 2026

F0rty-Tw0 force-pushed the bug/212/cant-resolve-cmd-bat-wrappers branch from a010a3e to f743361 Compare March 6, 2026 10:55

F0rty-Tw0 force-pushed the bug/212/cant-resolve-cmd-bat-wrappers branch from babb108 to 15d4159 Compare March 6, 2026 13:12

F0rty-Tw0 mentioned this pull request Mar 11, 2026

fix: PATHEXT resolution on Windows for JS/TS and Python tools #492

Closed

5 tasks

F0rty-Tw0 changed the base branch from master to develop March 11, 2026 09:42

F0rty-Tw0 force-pushed the bug/212/cant-resolve-cmd-bat-wrappers branch from 15d4159 to 89c2153 Compare March 11, 2026 10:47

fix: resolve Windows command wrapper execution

66eee97

- add PATHEXT-aware command resolution via which\n- migrate affected command runners to resolved_command\n- add regression coverage for wrapper/fallback behavior

F0rty-Tw0 force-pushed the bug/212/cant-resolve-cmd-bat-wrappers branch from 6648d40 to 66eee97 Compare March 11, 2026 21:02

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix windows PATHEXT resolution for .cmd/.bat wrappers#269

fix windows PATHEXT resolution for .cmd/.bat wrappers#269
F0rty-Tw0 wants to merge 1 commit intortk-ai:developfrom
F0rty-Tw0:bug/212/cant-resolve-cmd-bat-wrappers

F0rty-Tw0 commented Feb 26, 2026

Uh oh!

pszymkowiak commented Mar 2, 2026

Uh oh!

F0rty-Tw0 commented Mar 2, 2026

Uh oh!

FlorianBruniaux commented Mar 5, 2026

Uh oh!

pszymkowiak commented Mar 6, 2026

Uh oh!

F0rty-Tw0 commented Mar 6, 2026

Uh oh!

DylanDelobel commented Mar 9, 2026

Uh oh!

pszymkowiak commented Mar 11, 2026

Uh oh!

F0rty-Tw0 commented Mar 11, 2026

Uh oh!

F0rty-Tw0 commented Mar 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

F0rty-Tw0 commented Feb 26, 2026

What changed

Impact on existing code

Test plan

Uh oh!

pszymkowiak commented Mar 2, 2026

Uh oh!

F0rty-Tw0 commented Mar 2, 2026

Uh oh!

FlorianBruniaux commented Mar 5, 2026

Uh oh!

pszymkowiak commented Mar 6, 2026

Resolve Cargo.toml conflict (keep both: your which = "8" + upstream version bump)

Regenerate Cargo.lock with cargo update

Uh oh!

F0rty-Tw0 commented Mar 6, 2026

Uh oh!

DylanDelobel commented Mar 9, 2026

Uh oh!

pszymkowiak commented Mar 11, 2026

Uh oh!

F0rty-Tw0 commented Mar 11, 2026

Uh oh!

F0rty-Tw0 commented Mar 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Resolve Cargo.toml conflict (keep both: your `which = "8"` + upstream version bump)

Regenerate Cargo.lock with `cargo update`