Richard Siddaway's Blog

You usually start background jobs using Start-Job. Now you can start jobs with &. As of PowerShell v6.0 putting & at the end of a pipeline causes the pipeline to be run as a PowerShell job, for instance this pipeline:

PS> Get-Process | Sort-Object -Property CPU -Top 5

Is run as a background job by adding & to the end of the pipeline:

PS> Get-Process | Sort-Object -Property CPU -Top 5 &

When a pipeline is backgrounded, a job object is returned. Once the pipeline is running as a job, all of the standard job cmdlets can be used to manage the job. Variables (ignoring process-specific variables) used in the pipeline are automatically copied to the job so

Copy-Item -Path $path -Destination $dest &

just works without the need for the $using scope modifier or an argument list.

I recommend this technique for interactive working but that you use Start-Job in your scripts for more control (such as naming the job).

I’ve written a couple of times this year on the problems around the PowerShellGet module and the Scope (Allusers or CurrentUsers). The situation is a lot easier now that Install-Module and Update-Module Scope parameter is available.

Install-Module has always had a Scope parameter.

Update-Module has a Scope parameter as of PowerShell v6.2.1 and Powershell v7.0 preview 1.

I’ve changed mu profile to define the Scope parameter for both cmdlets as a default parameter:

$PSDefaultParameterValues = @{‘Install-Module:Scope’=’AllUsers’; ‘Update-Module:Scope’=’AllUsers’}

The rules for Install-Module default scopes seem to have changed with them now being:

When no Scope is defined, the default is set based on the PowerShellGet version.

In PowerShellGet versions 2.0.0 and above, the default is CurrentUser, which does not require elevation for install.

In PowerShellGet 1.x versions, the default is AllUsers, which requires elevation for install.

The documentation hasn’t caught up to Update-Module but past experience suggests it follows the same rules.

This is a good change as it gives back control of where the user puts the module, Too much software these days forces the developer’s assumptions on the user with no option to override. Its good to get the control back

In Windows PowerShell if you do something like this:

PS> (1..20 | Sort-Object -Property {$_ % 3}) -join ‘ ‘
9 6 12 15 3 18 19 16 13 10 4 1 7 20 17 2 8 11 5 14

The results come back in an unexpected order. This is not a stable sort as the results are sorted by their modulus result but lose the order within each group.

If you want a stable sort – where the results come back from a calculation like this in the order in they were received you need to add the –Stable switch. BUT that was added to PowerShell v6.1 and later

PS> (1..20 | Sort-Object -Property {$_ % 3} -Stable ) -join ‘ ‘
3 6 9 12 15 18 1 4 7 10 13 16 19 2 5 8 11 14 17 20

The results are sorted by modulus result and correctly within each group of modulus results

You could also use the Top or Bottom parameters:

PS> (1..20 | Sort-Object -Property {$_ % 3} -Top 20 ) -join ‘ ‘
3 6 9 12 15 18 1 4 7 10 13 16 19 2 5 8 11 14 17 20
PS> (1..20 | Sort-Object -Property {$_ % 3} -Bottom 20 ) -join ‘ ‘
3 6 9 12 15 18 1 4 7 10 13 16 19 2 5 8 11 14 17 20

If you alter the values presented to Top and Bottom you’ll get a subset of the results

PS> (1..20 | Sort-Object -Property {$_ % 3} -Top 10 ) -join ‘ ‘
3 6 9 12 15 18 1 4 7 10
PS> (1..20 | Sort-Object -Property {$_ % 3} -Bottom 10 ) -join ‘ ‘
13 16 19 2 5 8 11 14 17 20

Sort-Object in PowerShell Core has an interesting set of additions compared to Windows PowerShell.

OpenSSH installation has got a lot simpler in Windows 10 1809; Windows Server 2019 and Windows Server 1809.

OpenSSH is available as an optional feature. The client is preinstalled when you install the operating system. You just need to install the server:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Installing the optional feature creates the required firewall rule which is good.

You still need to make changes to the sshd_config file to enable password and pubkey authentication. The subsystem isn’t configured for PowerShell.

There’s a bug in OpenSSH so that subsystem paths with spaces aren’t parsed so you need to create a symbolic link for the PowerShell v6 folder.

if you want to use key-pair authentication the OpenSSHUtils module on the PowerShell gallery has bugs so you need to manually set the permissions on the authorized_keys file.

SSH remoting has a lot to offer but incorrect documentation, the work needed to install and configure it and buggy software will stop people using it. On the plus side OpenSSH is getting easier to install and configure but its still a long way from good.

PowerShell Core v6.2.1 has been released – https://github.com/PowerShell/PowerShell/releases

as has v6.1.4

The new versions are to primarily fix the Security Vulnerability CVE-2019-0733 – https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0733

v6.2.1 also enables tab completion for functions

The What’s new in PowerShell v6.2 is available at – https://docs.microsoft.com/en-gb/powershell/scripting/whats-new/what-s-new-in-powershell-core-62?view=powershell-6 – together with the already existing documents for PowerShell v6.0 and v6.1.

Its worth reading through the three documents – one each for v6.0, v6.1 and v6.2 to see the whole range of changes in PowerShell core.

A recent post – https://devblogs.microsoft.com/powershell/the-next-release-of-powershell-powershell-7/ – on the PowerShell team blog states that the next release of PowerShell Core won’t be 6.3 as expected but will be PowerShell 7

PowerShell 7 will be tied to .NET Core 3.0 and should bring more compatibility for Windows users. The graphic on the post shows Linux usage outstrips Windows usage of PowerShell Core by at least 5 to 1.

The lifecycle will change to align more closely with .NET Core with Long Term Servicing releases and non-LTS releases.

PowerShell 7 will eventually ship side-by-side with Windows PowerShell 5.1 but update process hasn’t been finalised.

Terminology changes are in the offing as PowerShell core is dropped for just PowerShell. This is a mistake as it takes away the use of PowerShell as a generic term that covers all versions.

The reasons for the change aren’t fully explained in the post but I suspect are linked to the very poor level of take up of PowerShell Core on Windows.

PowerShell v6.2 contains a number of experimental features including PSCommandNotFoundSuggestion

The idea of experimental features is to make the use of new features – especially those that may cause breaking changes optional. Feedback can be obtainied and the experimental features can be modified, moved out of the experimental state into the full release or even removed.

Use

Enable-ExperimentalFeature –Name PSCommandNotFoundSuggestion

to enable the feature. Then restart PowerShell.

Trying the new feature gave these results

PS> Get-Srvice

Suggestion [4,General]: The most similar commands are: Get-Service, Set-Service, New-Service, Get-PSDrive.

I expected Get-Service so that worked

Likewise

PS> Get-prcss

Suggestion [4,General]: The most similar commands are: Get-Process, Get-Alias, Get-Host, Get-Acl.

Looking for Get-Process – some of the other choices are very odd

Moving to native utilities

PS> pong

Suggestion [4,General]: The most similar commands are: popd, copy, move, ni, nv, oh, rni, rnp, sort, man.

I’d have expected to see ping in that list!

PS> Get-NtAdter

gives

Suggestion [4,General]: The most similar commands are: Get-NetAdapter, Set-NetAdapter, Get-Counter, Get-Item, Get-Date, Get-Member.

Expected Get-NetAdapter so that counts as a success.

Looking at aliases

PS> seloct

Suggestion [4,General]: The most similar commands are: select, sort, set, del, clc, sal, sl, sleep, start, sls.

PS> stv

Suggestion [4,General]: The most similar commands are: sv, stz, clv, ft, gpv, gv, nv, rv.

Needed to see select and stz respectively so that’s good.

One last utility

PS> ipconfog

Suggestion [4,General]: The most similar commands are: ipmo, ipcsv, ipconfig.exe, inmo.

ipconfig fits the bill.

For the most part the suggested commands seem to be reasonable and reasonably accurate.

Tab completion probably removes some of the usefulness of this option but I’d recommend enabling it and giving it a try

I’ve mentioned the PowerShell v6.2 experimental features before.

This blog post from the PowerShell team https://devblogs.microsoft.com/powershell/general-availability-of-powershell-core-6-2/

gives a good overview of the available experimental features.

I’ve already covered the use of the temp drive. The command not found suggestions and implicit remoting batching look like they could be useful.  The abbreviation expansion could make interactive use more efficient

The Powershell v6.2 release has just been made available on github – https://github.com/PowerShell/PowerShell/releases

The full release notes aren’t available on the Microsoft documentation yet – they should appear in the What’s New section of https://docs.microsoft.com/en-us/powershell/scripting/overview?view=powershell-6

The release notes on github indicate only one breaking change  – around the –NoEnumerate behaviour in Write-Output

There are some relatively minor cmdlet updates and fixes – nothing leaps out as a major issue.

You have six months to upgrade to v6.2 before the v6.1 support stops