Monthly Archive

Categories

Monthly Archives: June 2019

Start Jobs with &

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).

Install-Module and Update-Module Scope parameter

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