PowerShell 7.3 General Availability
We’re proud to announce the general availability of PowerShell 7.3! PowerShell 7.3 is built on top of .NET 7 and as a non-LTS (Long Term Support) release will be supported for 18 months. PowerShell 7.2 is still the current LTS (3-year supported) release of PowerShell.
How do I get it?
Since PowerShell 7 is supported on Windows, Linux, and macOS, there are a variety of ways to get it. If you had installed the previous PowerShell 7 stable release (7.2) via the Windows Store, you will be automatically updated to 7.3 GA. However, if you installed the MSI and chose to be updated via Microsoft Update, since 7.2 is a LTS release, you will not be automatically upgraded to 7.3 and needs to be manually installed.
What’s new?
You can see a video of demos I presented at this year’s PSConfEU minicon. It covers some of the major changes including new features and important bug fixes. Lots of the work presented were contributions fromm the community!
Known issues
We found a last minute issue that should not affect most users that we will fix in an expected 7.3.1 release in December. Due to an issue with our framework dependent package to be included with the .NET SDK Docker images, the .NET 7 GA SDK image will still have PowerShell 7.3-rc.1 included. This should not have any functional impact to users and we expect to update the image with PowerShell 7.3 GA in December.
Focus on the shell
The major theme for this release is focusing on making PowerShell 7 a great shell environment. Here, “native command” means an executable that is not a PowerShell cmdlet or function.
Improvement to native command argument passing
Windows and Linux/macOS have fundamental differences in how native command arguments are handled specifically when quotes are involved.
We added a new feature $PSNativeCommandArgumentPassing
to control how PowerShell passes arguments to native commands.
The default behavior for Windows and Linux/macOS should work as most users expect in their respective environments.
Another area to make native commands work more like cmdlets is error handling. Unlike cmdlets, native commands use their exit code to convey success or failure.
Consistency in error handling for native commands
Although stderr is often used for error messages,
it is also used for progress, information, warnings, etc. because native commands don’t have the rich streams that PowerShell cmdlets have.
Although a non-zero exit code does NOT always indicate an error, the convention for native commands is that a non-zero exit code typically indicates an error.
A new feature $PSNativeCommandUseErrorActionPreference
allows you to have PowerShell treat a non-zero exit code as an error.
This means that you can set $ErrorActionPreference
to Stop and have PowerShell stop execution whether a cmdlet had an error or a native command had a non-zero exit code.
This simplifies scripts that previously would have to check $LASTEXITCODE
after execution of a native command or wrap it in a helper function.
What’s next?
PowerShell 7.4 will be our next LTS release and expected to be built on .NET 8 for next year. We’ll have a separate blog post early next year to discuss the investments of the PowerShell/OpenSSH team for 2023. We appreciate all the efforts of the community, both individuals and working group members, and look forward to your continued feedback and contributions!
Light
Dark
6 comments
Very useful changes, especially the “native command argument passing” change, it finally fixes long-standing bugs, also fixed “error handling for native commands” is gold in some cases. 👍
Can I find a written list of major changes and new feature instead of a video somehwere?
Changelog is maintained here > https://github.com/PowerShell/PowerShell/tree/f404e39bc9215c0577a7a5220be16b25ae3ea51a/CHANGELOG
Thank you! I’m sure video is great for some, but it really lacks the accessibility of text.
Is $PSNativeCommandArgumentPassing considered as breaking change? I just installed new PS and our script that use [dotnet sln add “path”] stopted working.
I love PowerShell thank you for all of your efforts. I want to thank the whole team.
Since PowerShell is dependent on .NET and hence it’s major release and LTS coincide. Breaking changes in .NET become breaking changes in PowerShell. My I recommend considering 7.4 be named 8.0 to match .NET and following the same LTS Plan.