Tuesday, October 29, 2019

PowerShell 7 Preview 5 Ships

The PowerShell team has shipped another Preview release of PowerShell 7, dubbed Preview 5 (aka P5). P5 both brings great new features and takes us a big step closer to the release of PowerShell 7. Steve Lee posted details of what is in PowerShell V5 in a blog article.

For me there are a couple of notable additions:

The new Pipeline Chain Operators allow conditional execution of commands depending on whether the previous command succeeded for failed:
##  The code:
"Hello" && "There"
# # Produces
## The code
"Hello" || "There"
## Produces
I suspect we'll see a lot of code starting to use this. But: be careful I suspect a lot of 3AM confusions unless usage is well documented in your scripts.

An interesting feature is the New PowerShell Version notification. When you run PowerShell (P5 or later), during startup PowerShell detects that a newer version is available for download. 

Another cool feature added is adding emphasis to the output of Select-String. Select-String enables you to parse strings using regular expressions. With P5, the matches of the regular expression is highlighted like this:

My favourite new feature is the new condenses error view combined with the Get-Error cmdlet that expands the error report (it is a lot easier than $Error[0] | FL * -Force). Here is an example of what you are going to see:

Why does this matter?
That is one of my favourite questions - after all, it;'s a preview so why should you care? Well for a start, PowerShell 7 is shaping up to be aa huge improvement on the PowerShell experience with Windows PowerShell 5.1. I use it today in my day to day operations and find all the myriad of improvements large and small (I LOVE the CD - feature). If you are using Windows PowerShell today, you should download the Preview (or, if you are brave, the daily build) and start to experiment. 

One significant ad as yet not fully addressed issue with PowerShell 7 is around Cmdlet Coverage. There is no use in a fantastic shell if the cmdlets you use do not work, The change from using the full .NET framework to using .NET Core means that many cmdlets just do not work (and many never will).

The Windows Compatibility module provides partial relief. For example, you can easily use it to load the Server Manager module to allow you to manage Windows Features (i.e. on a Windows Server system). But some modules are not supported this way. For example, the WSUS module is not usable with Windows Compatibility. It's easy to say that the WSUS cmdlet design was poor (it relies on method calls vs using actual cmdlets) - but you are not going to be able to manage WSUS with PowerShell 7 for some time. But this IS a work in progress and I am certain the PowerShell team are taking the feedback on board to enable a better solution to backwards compatibility (although in some cases, the real solution is for the cmdlet designers to re-implement their cmdlets using .NET Core).

Wednesday, October 02, 2019

PowerShell 7's Ternary Operator

The PowerShell 7 team have just released a new PowerShell 7 Preview build. This contains a new, and interesting, new operator, the ternary operator.

This operator is, in effect, a short cut to If/Else. Thus, instead of:

$Message = If ($IsWindows) {"Is Windows"} Else {"Is NOT Windows"}
The Ternary operator allows you to simplify

$Message = $IsWIndows ? "Is Windows" : "Is NOT Windows" 

So a cool new feature coming to PowerShell 7. It is available in the latest Preview but as an Experimental feature. Experimental features in PowerShell 7 are features you turn ON and OFF as you like. By default, experimental features are turned off until you turn them on. To view them and turn them on is simple - just use Get-ExperimentalFeature and Set-ExperimentalFeature like this. 

A relevant question is whether you SHOULD use this operator. For simple things, such as the snippets above, it does enable a more compact script. at the expense of potential confusion by folks not versed in the new syntax. It may not pass the "Three AM test" (ie can you easily and simply work out a bug in this code when woken up at 3 in the morning?). 

Additionally, in my testing, this operator is sometimes a little faster than the old fashioned approach, but there is not a lot in it:

So a new operator, which you have to enable explicitly. It does offer some small performance gains in some cases. Coming soon to a Powershell 7 near you!