fix(task): append forwarded args to inline bash -c tasks on windows#10321
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThis PR fixes how forwarded CLI arguments are passed to bash subshell tasks. The task executor now distinguishes POSIX shells (e.g. ChangesTask shell argument forwarding
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
Greptile SummaryThis PR fixes a Windows-only argument-forwarding bug where inline TOML tasks using a POSIX shell (
Confidence Score: 5/5The change is a narrow, well-tested fix to a Windows-only arg-forwarding path with no impact on Unix behavior. The logic in task_executor.rs is correct and both platforms have dedicated test coverage. e2e-win/task.Tests.ps1 follows the same CWD-vs-TestDrive file-writing pattern as other tests; verify CI runner CWD matches TestDrive. Important Files Changed
Reviews (2): Last reviewed commit: "fix(task): append forwarded args to inli..." | Re-trigger Greptile |
On Windows, an inline task with an explicit POSIX shell (e.g. `shell = "bash -c"`) passed forwarded args as separate argv to `bash -c <script> arg1 ...`, so bash assigned the user's first arg to `$0` and it was silently swallowed. Inline TOML scripts are documented to append forwarded args to the command string (only file/shebang tasks get real positional params), which the Unix branch already did. For Windows POSIX shells, fall through to the same shared `shell_words::join` append after the cmd.exe verbatim early-return, so `$0` stays "bash" and the args reach the command, matching Unix. Non-POSIX non-cmd shells (e.g. `pwsh -Command`) keep passing args as separate argv, since `shell_words` uses POSIX quoting that PowerShell would not parse back into the original argument. Adds a Unix e2e assertion (`e2e/tasks/test_task_shell`) and a Windows e2e test (`e2e-win/task.Tests.ps1`). Refs jdx#9355. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
86e3e72 to
31cc5ea
Compare
Problem
On Windows, an inline task with an explicit POSIX shell (e.g.
shell = "bash -c") passed forwarded args as separate argv tobash -c <script> arg1 …. bash then assigned the user's first forwarded arg to$0, so it was silently swallowed:mise run args_repro -- myargprintedusing shell myarginstead ofusing shell bash myarg.Fix
Inline TOML scripts are documented to append forwarded args to the command string (only file/shebang tasks get real positional params), which the Unix branch already did. For Windows POSIX shells, fall through to the same shared
shell_words::joinappend after thecmd.exeverbatim early-return, so$0staysbashand the args reach the command — matching Unix behavior.Non-POSIX, non-
cmdshells (e.g.pwsh -Command) keep passing args as separate argv, sinceshell_wordsuses POSIX quoting that PowerShell would not parse back into the original argument.Tests
e2e/tasks/test_task_shell— Unix assertion thatmise run shell -- myargyieldsusing shell bash myarg.e2e-win/task.Tests.ps1— Windows test reproducing the arg-swallow bug (skips when Git Bash / MSYSbash.exeisn't on PATH).Refs #9355.
🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes
Tests