PowerShell wrapper emits bash PIPESTATUS syntax causing parse failure and wrong exit propagation

[raspy]

Summary

On Windows PowerShell, the rewritten command includes a bash-style pipeline exit expression. This leads to:

1. PowerShell parse/runtime error for the exit expression.
2. Incorrect command status handling in hook-managed execution.

Environment

VSCode with GitHub Copilot on Windows 11

Observed behavior

The wrapped command tail includes a suffix equivalent to:

... | boost; (exit ${PIPESTATUS[0]:-$pipestatus[1]})

In PowerShell, this syntax is not valid.

Expected behavior

1. Windows PowerShell wrappers should be PowerShell-native.
2. Exit status should match the pre-pipe command exit (PIPESTATUS[0] intent), not the post-pipe tool exit.

Impact

1. False-negative command failures in agent/tooling flows.
2. Broken automation and noisy diagnostics.
3. Ambiguous success/failure outcomes.

Minimal repro (anonymized)

1. Enable hook integration in a Windows PowerShell environment.
2. Run a simple command through the rewritten wrapper.
3. Observe parse error or incorrect non-zero behavior tied to the wrapper tail expression.

Proposed fix

1. Do not emit bash PIPESTATUS syntax for PowerShell targets.
2. For PowerShell wrappers, preserve pre-pipe exit by capturing $LASTEXITCODE before piping:
   • run original command
   • capture $LASTEXITCODE into a variable
   • pipe output to boost
   • exit with captured variable
3. Keep shell-specific rewrite logic separated by target shell.

Acceptance criteria

1. No PowerShell parse/runtime error in wrapped commands.
2. Success path returns success when original command succeeds.
3. Failure path returns original command failure code even when piped through boost.
4. Behavior consistent across Windows PowerShell 5.1 and PowerShell 7+.

Privacy note

This report intentionally excludes repository names, user paths, hostnames, tokens, and proprietary command content.

[aviram-ashkenazi-jfrog]

Hi @raspy ,
Thanks for reporting the issue.