We’re proud to announce that the latest version of PowerShell has been released!

This is the third minor supported release of PowerShell Core, the open-source edition of PowerShell that works on Linux, macOS, and Windows!

Thanks to everyone that made this release possible, including our contributors, users, and anyone who filed issues and submitted feedback.

So How Do I Install It?

For info on installing PowerShell Core 6.2, check our installation docs.

A reminder that PowerShell Core works side-by-side with Windows PowerShell, so you can use both independently of each other. This means that you can continue to use Windows PowerShell for existing scripts while simultaneously using PowerShell Core for new automation or to explore its new capabilities.

What’s New?

The PowerShell Core 6.2 release is focused primarily on performance improvements, bug fixes, and smaller cmdlet/language enhancements that improve the quality of life for users. To see a full list of improvements, check out our detailed changelogs on GitHub.

Since the 6.1.0 release (September 2018), we’ve taken over 560 changes for the 6.2 release! That’s almost 4 changes a day (excluding weekends)! Of course, we have to thank our community for providing a significant portion of these improvements. Per our public PowerBI dashboard, the community is still contributing just over half of all incoming pull requests!

Throughout the development of 6.2, the PowerShell Core team has also been focused on supporting PowerShell Core 6 in Azure Functions (more on this soon!), automating our release process (blog coming!), the v1.18.0 release of PSScriptAnalyzer, the 2.0.0-Preview release of the PowerShell Visual Studio Code extension, and, of course, the PowerShell Core 6.2 release.

Experimental Features

In the 6.1 release, we enabled support for Experimental Features which allow contributors and PowerShell Team members to deliver new features and get feedback before we consider the design complete and to avoid making breaking changes as the design evolves. It’s often easier to provide feedback by experimenting with working code than from reading a specification that describes the user experience.

In the 6.2 release, we have a number of Experimental Features you can try out. We’d love it if you can provide us with feedback on these so we can make improvements, decide whether it’s worth keeping, or promote it out of an experimental state.

At any time you can use Get-ExperimentalFeature to get a list of available experimental features that can be enabled or disabled with Enable/Disable-ExperimentalFeature.

Command Not Found Suggestions

Enable-ExperimentalFeature -Name PSCommandNotFoundSuggestion

This feature will use fuzzy matching to find suggestions of commands or cmdlets you may have meant to type if you made a typo.

PS> Get-Commnd
Get-Commnd : The term 'Get-Commnd' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-Commnd
+ ~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Get-Commnd:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException


Suggestion [4,General]: The most similar commands are: Get-Command, Get-Content, Get-Job, Get-Module, Get-Event, Get-Host, Get-Member, Get-Item, Set-Content.

In this example, I mistyped Get-Command and it fuzzy matched to a number of suggestions from most likely to least likely.

Implicit Remoting Batching

Enable-ExperimentalFeature -Name PSImplicitRemotingBatching

When using implicit remoting in a pipeline, PowerShell treats each command in the pipeline independently. This results in objects being serialized and de-serialized between the client and target system repeatedly over the execution of the pipeline.

With this change, PowerShell analyzes the pipeline and determines if the command is safe to run or the command exists on the target system and is able to execute the entire pipeline remotely and only serialize and de-serialize the results back to the client.

This can result in significant performance gains! A real-world test of Get-Process | Sort-Object over localhost shows a decrease from 10-15 seconds to a 20-30 milliseconds, a speed increase of 300-750x. This should be even faster going over a real network connection, and only requires you to update your client (no changes to the server side are necessary).

Temp Drive

Enable-ExperimentalFeature -Name PSTempDrive

If you’re using PowerShell Core on different operating systems, you’ll discover that the environment variable for finding the temporary directory is different on Windows, macOS, and Linux! With this feature, you will get a PSDrive called Temp: that is automatically mapped to the temporary folder on whichever operating system you are using.

PS> "Hello World!" > Temp:/hello.txt
PS> Get-Content Temp:/hello.txt
Hello World!

Be aware that native file commands (like ls on Linux) are not aware of PSDrives and won’t see this Temp: drive.

Abbreviation Expansion

Enable-ExperimentalFeature -Name PSUseAbbreviationExpansion

PowerShell cmdlets are expected to have descriptive nouns. This can results in long names that can take time to type and make it easier to make typing mistakes. This feature allows you to just type the uppercase characters of the cmdlet and use tab-completion to find a match.

PS> i-arsavsf

If you hit tab, and have the Azure PowerShell Az module installed, it will autocomplete to:

PS> Import-AzRecoveryServicesAsrVaultSettingsFile

Note that this feature is intended to be used interactively so the abbreviated forms of cmdlets won’t work in scripts. This is not intended to be a replacement for aliases.

How can I provide feedback?

As always, you should file issues on GitHub to let us know about any features you’d like added or bugs that you encounter. Additionally, you can join us for the PowerShell Community Call on the 3rd Thursday of every month.

Being an Open Source project, we value all types of contributions including code, tests, documentations, issues, and discussion.

We have an amazing active community and this release would not have been possible without you!

The Future

We are still working out our plans for the next release. Stay tuned for our roadmap to be published on this blog!

On behalf of the PowerShell Team,

Steve Lee Principal Software Engineering Manager PowerShell Team https://twitter.com/Steve_MSFT