Change $PSNativeCommandArgumentPassing to default to Legacy on stable release and Windows on previews

[SteveL-MSFT]

Summary of the new feature / enhancement

Given the impact to users with the 7.3.0 release, proposal is to change the default of $PSNativeCommandArgumentPassing to Legacy on Windows (still Standard on non-Windows). We would keep the default as Windows on Windows for preview releases. This would be backported to 7.3.x

This was discussed and approved by @commi

Proposed technical implementation details (optional)

No response

[inikulshin]

Also, when I do

$PSNativeCommandArgumentPassing = 'Legacy'
...
Start-Job -ScriptBlock { . "$using:path\$using:command" @using:escapedArgs }

I expect to script block to inherit passing behavior ('Legacy' in my case).
However I'm not sure if script block doesn't inherit all global variables (and it's expected behavior) or only this one.

[mklement0]

@inikulshin, this is a separate issue: script blocks that run in the context of background jobs know nothing about the caller's state (the only exception are environment variables); any such state must be recreated explicitly, as needed: (Start-Job { $PSNativeCommandArgumentPassing = $using:PSNativeCommandArgumentPassing; ... }); that said, there's a proposal for thread-based parallelism to allow inheriting the caller's state on demand - see #12240 (it is in the context of ForEach-Object -Parallel, but it should be added to Start-ThreadJob too; thread-based jobs are generally preferable to child-process-based ones).

[mklement0]

With respect to the issue at hand:

• See Add msbuild to NativeCommandProcessor (s_legacyCommands) in PWSH 7.3 #18660 (comment) for a potential way forward that avoids the inherently problematic need for a preference variable.

[SteveL-MSFT]

Recently I hit an issue that makes me reconsider this change. I have a native command that accepts JSON as input to parameters. With Legacy mode, all the double quotes get dropped so it's no longer valid JSON. It took a bit of work to figure out that was the problem and I don't see normal users figuring that out (it was made more difficult because it worked on my local machine which defaulted to Windows mode while CI/CD was 7.2 which only has Legacy mode).

[mklement0]

@SteveL-MSFT, let us recap:

• PowerShell's argument-passing to native programs has been broken since v1, with respect to passing arguments with embedded " chars. and passing an empty string as an argument.

• Generations of PowerShell users have learned to live with this bug, employing workarounds that build on the broken behavior.

• In v7.3.0, a breaking change was foisted upon unsuspecting users, which broke all existing workarounds. I say "unsuspecting", because the only reference to it in the relevant release notes in no way, shape or form did justice to the ramifications of this change.

  • The nature of that breaking change introduced a half-fix on Windows, inexplicably selectively retaining the old, broken behavior via the ill-fated Windows mode of the newly introduced $PSNativeCommandArgumentPassing preference variable.

Based on your comment, it sounds like you're now considering retaining the half-broken behavior going forward.
This is the worst of both worlds:

• It forces modification of existing code in order to continue to work, i.e. constitutes a serious break of backward compatibility.

• It forces new users to grapple with the obscure behavior of Windows mode.

See also: #18660 (comment)

[SteveL-MSFT]

@mklement0 will bring this topic back up to the committee. Based on your proposal, we'll just stick with Legacy on Windows forever, which IS an option.

[SteveL-MSFT]

@PowerShell/powershell-committee re-discussed this. We debated on whether we prioritize existing PowerShell users (primarily Windows-only) or for new/existing customers that may encounter issues with new commands that don't work with legacy mode and may not figure out how to escape properly.

In short, we decided that we would prioritize cross-platform compat the future than WinPS compat and the past. One action item we will be taking is adding telemetry to detect if people are changing the mode as this will inform us if we need to revisit the default.

At this time, we plan to continue evolving Windows mode rather than switching to Standard mode on Windows. This was not an easy discussion and we'll continue to monitor feedback.

[ghost]

This issue has been marked as declined and has not had any activity for 1 day. It has been closed for housekeeping purposes.

[mikeharder]

@SteveL-MSFT: Is there definitive documentation or guidance from the PowerShell team for how script authors should react to these changes? So far the best documentation I have found are these resources:

https://stackoverflow.com/a/74440425
#13428 (comment)

@mklement0: Thank you for creating these docs!

Stack Overflow

PowerShell 7.3.0 breaking command invocation

I use WinSCP within a Powershell script. It suddenly stopped working. After a while I could figure out that the problem appeared from a more recent version of PowerShell: Reduced code: & winscp...