{"id":18566,"date":"2020-08-17T14:33:46","date_gmt":"2020-08-17T22:33:46","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/powershell\/?p=18566"},"modified":"2020-08-17T14:33:46","modified_gmt":"2020-08-17T22:33:46","slug":"powershell-7-1-preview-6","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/powershell-7-1-preview-6\/","title":{"rendered":"PowerShell 7.1 Preview 6"},"content":{"rendered":"

Today, we are releasing the sixth preview of the PowerShell 7.1 release<\/a>!<\/p>\n

Further in this blog post I’ll provide details on some important changes you should be aware of as you\nstarting trying out this preview.<\/p>\n

PowerShell 7.1 Roadmap update<\/h2>\n

We are planning the last preview release around the first week of September.\nThis will allow us to get in the last of our significant code changes before we start minimizing risk (and code churn) for our Release Candidate.<\/p>\n

We expect our first Release Candidate in the second half of September.\nRelease Candidates are “go-live” meaning they are supported in production.\nIf there is a critical security or blocking issue, we will provide an updated servicing release for a\nRelease Candidate.\nWe would like users to start deploying the Release Candidate so that we can address any major issues\nas we head towards a General Availability release at the end of this year.<\/p>\n

Unlike preview releases, Release Candidates will not<\/em> have Experimental Features enabled by default.\nSome Experimental Features will be taken out of experimental state and their designs will be considered\nfinal while others will stay in experimental state and will need to be explicitly enabled to continue use.<\/p>\n

As a reminder, Experimental Features are not considered design complete.\nThis means that the design may change based on real world usage feedback and such changes are not\nconsidered breaking changes.\nProduction code should not depend on experimental features.<\/p>\n

Noteworthy Changes<\/h2>\n

There are some changes in PowerShell 7.1 Preview 6 that are worth going into detail and some are breaking changes.<\/p>\n

Rename -FromUnixTime<\/code> to -UnixTimeSeconds<\/code> on Get-Date<\/code> to allow Unix time input<\/h3>\n

Unix time<\/a> is the number of seconds since January 1st, 1970 at 00:00:00 UTC.\nIn Preview 2 of PowerShell 7.1, we merged a community submitted pull request to add -FromUnixTime<\/code> to the Get-Date<\/code> cmdlet.\nHowever, it was discovered later that the prefix From<\/code> was inconsistent with existing parameters on that cmdlet.\nSo a change was accepted to simply call it -UnixTimeSeconds<\/code> which accepts a value in Unix time similar to how\n-Date<\/code> accepts a value in date time format.<\/p>\n

get-date -UnixTimeSeconds 1597615564\r\n<\/code><\/pre>\n
Sunday, August 16, 2020 3:06:04 PM\r\n<\/code><\/pre>\n
This feature was added by community member aetos382<\/a>!<\/p>\n
Make $ErrorActionPreference<\/code> not affect stderr<\/code> output of native commands<\/h3>\n
Native commands support three streams: stdin, stdout, and stderr.\nstdin<\/code> is for sending input to a native command.\nstdout<\/code> is for any output from a native command you might want to pass further down the pipeline.\nstderr<\/code> (despite “error” being in the name) is used for all other output.<\/p>\n
stderr<\/code> can include error messages, but also text content equivalent to PowerShell verbose, debug, and information streams\nas well as progress information or help text.<\/p>\n
The de facto standard way to determining if a native command has succeeded or failed is by looking at the exit code\n(in PowerShell this is by the $LASTEXITCODE<\/code> automatic variable).\nSince stderr<\/code> typically contains non-error information, it is not a reliable way to detect errors from native commands.<\/p>\n
Text output from stderr<\/code> are wrapped as ErrorRecord<\/code>s but tagged to indicate it is from stderr.\nPrior to this change, because these are ErrorRecord<\/code> instances, they would get added to the $Error<\/code> automatic variable\nwhich is a running log of errors.\nIf you set $ErrorActionPreference<\/code> to a value that affects execution (like Stop<\/code> or Inquire<\/code>) then any text written\nto stderr<\/code> would cause your script execution to be impacted.<\/p>\n
With this change, stderr<\/code> is just treated like an information stream (although it is still stream number 2 for redirection) and\nis not affected by $ErrorActionPreference<\/code> which also means stderr<\/code> output does not show up in $Error<\/code> nor does it\ncause $?<\/code> to be $false<\/code> indicating the last command failed.<\/p>\n
There is an existing RFC<\/a> to allow script execution to be impacted\nby native command exit code that we hope to be in a future version of PowerShell.<\/p>\n
Allow explicitly specified named parameter to supersede the same one from hashtable splatting<\/h3>\n
Splatting<\/a> is a feature in\nPowerShell allowing passing parameters to commands defined in a hashtable.\nFor example, if you have a script that calls the same or different cmdlets multiple times where the parameters and their\nvalues are the same, then instead of typing it multiple times you can define it once and pass the same hashtable\nto each cmdlet.\nIf a parameter or value changes, you would then just update the hashtable.<\/p>\n
$myParams = @{\r\n  Uri = 'https:\/\/api.github.com\/repos\/powershell\/powershell\/releases'\r\n  Method = 'Get'\r\n  FollowRelLink = $true\r\n}\r\n\r\nInvoke-RestMethod @myParams\r\n<\/code><\/pre>\n
\n
Note: The above example shows how to pass the -FollowRelLink<\/code> switch using splatting<\/p>\n<\/blockquote>\n
In some scripts, you may want to override one of the values in the hashtable for a specific instance.\nPreviously, you would get an error that the parameter was already specified:<\/p>\n
Invoke-RestMethod @myParams -Uri https:\/\/api.github.com\/repos\/dotnet\/runtime\r\n<\/code><\/pre>\n
Invoke-RestMethod: Cannot bind parameter because parameter 'Uri' is specified more than once. To provide multiple values to parameters that can accept multiple values, use the array syntax. For example, \"-parameter value1,value2,value3\".\r\n<\/code><\/pre>\n
With this change, the above example now works as one would expect in that the -Uri<\/code> parameter value will be the one explicitly\nspecified in the command line and not the one in the hashtable.<\/p>\n
Experimental Feature: PSManageBreakpointsInRunspace<\/h3>\n
PowerShell has powerful built-in scripting debugging capabilities<\/a>.\nHowever, previously the debugging cmdlets would only allow you to manage breakpoints in the current PowerShell session (called a runspace).\nCommunity member Kirk Munro<\/a> added the ability to specify a different runspace to the breakpoint management cmdlets!<\/p>\n
$job = Start-Job { $pid; Start-Sleep -Seconds 5; Write-Verbose \"Hello\" }\r\n\r\n# wait until the job process starts\r\nwhile ($job.ChildJobs[0].Runspace.RunspaceStateInfo.State -ne 'Opened') {\r\n    Start-Sleep -Milliseconds 50\r\n}\r\nSet-PSBreakpoint -Command Write-Verbose -Action { break } -Runspace $job.ChildJobs[0].Runspace\r\n\r\n# wait until the job is waiting at the breakpoint\r\nwhile ($job.State -ne 'AtBreakpoint') {\r\n    Start-Sleep -Seconds 1\r\n}\r\n\r\n# get the job process id to debug it later\r\n$jobpid = $job | Receive-Job\r\n$job | Get-Job\r\n<\/code><\/pre>\n

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command\r\n--     ----            -------------   -----         -----------     --------             -------\r\n7      Job7            BackgroundJob   AtBreakpoint  True            localhost             Start-Sleep -Seconds 5;\u2026\r\n\r\n<\/code><\/pre>\n
# Connect to the running job process\r\nEnter-PSHostProcess -id $jobpid\r\n\r\n# Find the runspace where the running script is stopped at the breakpoint and attach debugger to it\r\nGet-Runspace | Where-Object { $_.Debugger.InBreakpoint -eq $true } | Debug-Runspace\r\n<\/code><\/pre>\n
Debugging Runspace: RemoteHost\r\nTo end the debugging session type the 'Detach' command at the debugger prompt, or type 'Ctrl+C' otherwise.\r\n\r\nHit Command breakpoint on 'Write-Verbose'\r\n\r\nAt line:1 char:32\r\n+  $pid; Start-Sleep -Seconds 5; Write-Verbose \"Hello\"\r\n+                                ~~~~~~~~~~~~~~~~~~~~~\r\n<\/code><\/pre>\n
Here you see that execution stopped exactly where we set the breakpoint.<\/p>\n
\n
Note: As the script is stopped at the breakpoint, it will wait indefinitely for a debugger to be attached<\/p>\n<\/blockquote>\n
Built in Pager for Get-Help<\/h3>\n
As part of additional work to improve the PowerShell help experience (more on this later!), we wrote our own pager to provide a consistent\nexperience across platforms.<\/p>\n
This is a work in progress so a bit limited in functionality currently.\nContributions and issues are certainly welcome in the Pager repo<\/a>.<\/p>\n
You can try it out using the new -Paged<\/code> switch with Get-Help<\/code>:<\/p>\n
Get-Help -Paged Get-Command\r\n<\/code><\/pre>\n
PSReadLine will leverage this pager for its new “Dynamic Help” feature where you can use a keyboard combination to get help while in the middle\nof typing out a command-line and being able to return to exactly where you left off!<\/p>\n
New -MaskInput<\/code> switch for Read-Host<\/code><\/h3>\n
This was a community requested feature to hide the input the user types.\nNormally, you would use -AsSecureString<\/code> for sensitive information that you would not want echoed onto the screen or end up in logs\/transcripts.\nHowever, there are scenarios where you don’t want to deal with a SecureString and prefer to get plain text.\nThis switch will still mask the input the user types, but returns a string.<\/p>\n
$input = Read-Host -MaskInput -Prompt \"Tell me a secret\"\r\n<\/code><\/pre>\n
Summary<\/h2>\n
There are, of course, many bug fixes and smaller improvements not mentioned in this blog post provided by both the community as well\nas the PowerShell team.\nWe have a few more important changes to get into the PowerShell 7.1 release before we hit our first Release Candidate in September.<\/p>\n
Early this month, the majority of PowerShell usage (not including Windows PowerShell) switched from PowerShell Core 6.2 to PowerShell 7.0!\nWe hit a high point of 4.5 million startups of pwsh<\/code> in a single day!\nSee more data at our public PowerBI dashboard<\/a>.\nReminder that PowerShell Core 6.2 support ends next month!<\/p>\n","protected":false},"excerpt":{"rendered":"
Update on PowerShell 7.1 release<\/p>\n","protected":false},"author":685,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[248],"class_list":["post-18566","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell","tag-powershell"],"acf":[],"blog_post_summary":"
Update on PowerShell 7.1 release<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/18566","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/685"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=18566"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/18566\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=18566"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=18566"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=18566"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}