You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
& operator launches commands differently in 7.3.0 #18568
Build C# app called blah.exe using Program.cs, make sure it's on the path.
Run pwsh -f test.ps1 and observe the output.
Expected behavior
On 7.2.7:Something will happen: working...Something will happen: done.--setdeployment.environment=blah--setdeployment.region=blah--setdeployment.image.repository=blah
Actual behavior
On 7.3.0:Something will happen: working...Something will happen: done.--setdeployment.environment="blah"--setdeployment.region="blah"--setdeployment.image.repository="blah"
Error details
No response
Environment data
Name Value
---------
PSVersion 7.3.0
PSEdition Core
GitCommitId 7.3.0
OS Microsoft Windows 10.0.19044
Platform Win32NT
PSCompatibleVersions {1.0,2.0,3.0,4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
This is ultimately a duplicate of #18554, but let me add some context:
v7.3.0 introduced a breaking change with respect to how arguments with embedded " characters as well as empty-string arguments are passed to external programs: a longstanding bug was fixed, fully on Unix, partially on Windows.
Existing workarounds that build on the old, broken behavior now break - except in calls to batch files and WSH scripts, where the legacy workarounds will continue to work by default.
For a summary of the impact on existing vs. future code, see this comment.
The fixed behavior now correctly escapes embedded " characters as \" on the process command line PowerShell constructs behind the scenes, which is the most widely observed convention on Windows, and also supports passing empty strings as arguments.
Thus, an argument such as "deployment.environment=`"blah`"", which from PowerShell's perspective has a verbatim value of deployment.environment="blah" is now placed as follows on the target process' command line: "deployment.environment=\"blah\"", and if the target process observes the aforementioned convention, it ends up parsing that again as verbatimdeployment.environment="blah", which is what you saw.
That GitHub link doesn't provide a cumulative view of what changed in that release - it just shows whatever changed in the final commit that led to the release.
As an aside: The post also suggests that the experimentalPSNativeCommandErrorActionPreference was made stable, but from what I can tell that isn't actually the case.
The content team should have plans to have an about topic specifically around using native commands in PS7 and I expect will capture these types of details
Steve Lee (@SteveL-MSFT) - given that this is the second report of this issue in as many days, I wonder if it might be wiser for the default value of $PSNativeCommandArgumentPassing to be legacy. ? I think (as Michael Klement (@mklement0) says) the previous behaviour was a bug, but one which so many had lived with for so long it became "standard" - I put this as an open question because what gives the best gain:pain ratio is not obvious to me :-)
Some of the 7.3 changes (PSReadline prediction being on, colouring directories, formatting of floating point in tables, the change to convertFrom-Json -as hash table, and this one) need to publicized more than they have been , the community can help on that but docs and team blog probably need to to take the lead. I'm for 3/5 of those, against 1/5, and this one I'm not sure about. Not all changes are bad, but surprises generally are, especially if the explanation is hard to find.
Reacted by Michael Klement, Markus Szumovski and Dave
Activity
mklement0 commentedon Nov 15, 2022
This is ultimately a duplicate of #18554, but let me add some context:
v7.3.0 introduced a breaking change with respect to how arguments with embedded
"characters as well as empty-string arguments are passed to external programs: a longstanding bug was fixed, fully on Unix, partially on Windows.$PSNativeCommandArgumentPassingto default toLegacyon stable release andWindowson previews #18694Existing workarounds that build on the old, broken behavior now break - except in calls to batch files and WSH scripts, where the legacy workarounds will continue to work by default.
To make such legacy workarounds work in v7.3.0, you need to set the
$PSNativeCommandArgumentPassingpreference variable (temporarily) to'Legacy'For a summary of the impact on existing vs. future code, see this comment.
The fixed behavior now correctly escapes embedded
"characters as\"on the process command line PowerShell constructs behind the scenes, which is the most widely observed convention on Windows, and also supports passing empty strings as arguments."deployment.environment=`"blah`"", which from PowerShell's perspective has a verbatim value ofdeployment.environment="blah"is now placed as follows on the target process' command line:"deployment.environment=\"blah\"", and if the target process observes the aforementioned convention, it ends up parsing that again as verbatimdeployment.environment="blah", which is what you saw.There's additional background information in this Stack Overflow answer.
wasker commentedon Nov 15, 2022
Thank you for the links!
There's no mention of this behavior change in relnotes for 7.3.0 - https://github.com/PowerShell/PowerShell/releases/tag/v7.3.0
mklement0 commentedon Nov 15, 2022
My pleasure, wasker.
That GitHub link doesn't provide a cumulative view of what changed in that release - it just shows whatever changed in the final commit that led to the release.
While you could infer the cumulative changes from https://github.com/PowerShell/PowerShell/releases,
the official what's-new summary for a given release should be at https://learn.microsoft.com/en-us/powershell/scripting/whats-new/overview
However, as of this writing, https://learn.microsoft.com/en-us/powershell/scripting/whats-new/what-s-new-in-powershell-73 does not contain the relevant information.
The PowerShell Team blog at https://devblogs.microsoft.com/powershell/powershell-7-3-general-availability/ at least mentions the feature that caused the breaking change, but, to my mind, that description is inadequate, given that the fact that it is breaking isn't even mentioned.
PSNativeCommandErrorActionPreferencewas made stable, but from what I can tell that isn't actually the case.SteveL-MSFT commentedon Nov 16, 2022
cc Mikey Lombardi (He/Him) (@michaeltlombardi)
The content team should have plans to have an about topic specifically around using native commands in PS7 and I expect will capture these types of details
mklement0 commentedon Nov 16, 2022
See also:
jhoneill commentedon Nov 16, 2022
Steve Lee (@SteveL-MSFT) - given that this is the second report of this issue in as many days, I wonder if it might be wiser for the default value of
$PSNativeCommandArgumentPassingto belegacy. ? I think (as Michael Klement (@mklement0) says) the previous behaviour was a bug, but one which so many had lived with for so long it became "standard" - I put this as an open question because what gives the best gain:pain ratio is not obvious to me :-)Some of the 7.3 changes (PSReadline prediction being on, colouring directories, formatting of floating point in tables, the change to convertFrom-Json -as hash table, and this one) need to publicized more than they have been , the community can help on that but docs and team blog probably need to to take the lead. I'm for 3/5 of those, against 1/5, and this one I'm not sure about. Not all changes are bad, but surprises generally are, especially if the explanation is hard to find.