Powershell: Invoke-Command does not apply VerbosePreference to ScriptBlock

Created on 18 Jun 2017  路  7Comments  路  Source: PowerShell/PowerShell

Steps to reproduce

PowerShell 6Beta2 still has the same gotcha as Windows PowerShell that one needs to manually pass and set the VerbosePreference into scriptblocks, even when using advanced functions. It would be nice if the VerbosePreference of the Invoke-Command Cmdlet would be set automatically in the executed scriptblock.

Invoke-Command -ScriptBlock {Write-Verbose "Hello World"} -Verbose

Invoke-Command -ScriptBlock {[CmdletBinding()]Param() Write-Verbose "Hello World"} -Verbose

Expected behavior

I would expect in both cases that the VerbosePreference gets applied automatically
VERBOSE: Hello World

Actual behavior

No verbose output.
One has to pass and set it manually to get it working:
Invoke-Command -ScriptBlock {[CmdletBinding()]Param($VerbosePreference) Write-Verbose "Hello World"} -Verbose -ArgumentList ('Continue')

Environment data

Name                           Value
----                           -----
PSVersion                      6.0.0-beta
PSEdition                      Core
BuildVersion                   3.0.0.0
CLRVersion
GitCommitId                    v6.0.0-beta.2
OS                             Microsoft Windows 10.0.15063
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
Issue-Discussion

Most helpful comment

Here is a related RFC.

All 7 comments

@bergmeister I see the ask here, but how would you specify that you want -Verbose on the Invoke-Command, and not on the -ScriptBlock? You'd still have to provide a way to do that.

@pcgeek86 My impression was that with the general usage of -Verbose is that one either gets no verbose output or everything. For example consider when calling function A that calls function B internally, the VerbosePreference propagates from A to B by default without doing anything. That's why I thought that this would be the more common and intuitive default and in the special case if one really wanted the Verbose output from Invoke-Command only but not the ScriptBlock one could still pass the desired VerbosePreference to the ScriptBlock as Invoke-Command -ScriptBlock {[CmdletBinding()]Param($VerbosePreference) Write-Verbose "Hello World"} -Verbose -ArgumentList ('SilentlyContinue')
This is certainly a more philosophical discussion but to me it would make the behaviour more consistent and intuitive. Should the outcome of this discussion be a change, then one would most certainly also need to include other preferences such as InformationPreference (and maybe even the WhatIfPreference).

I too ran into the same problem with not understanding why my verbose statements within an Invoke-Command were not outputting. It is confusing and adds extra work.

If you think about it, the expectation with Invoke-Command is to execute all statements within the script block remotely. Output is already routing back to the local terminal session to be displayed. So when you see Write-Verbose statements, and -Verbose set on the Cmdlet, you expect it to show up.

As for the conflict with Invoke-Command having it's own Verbose statements, as far as I can tell, there are none. If there were, it wouldn't be an issue with -Debug or -Verbose showing the connection activities mixed in with my Verbose. It could actually help if something were broken in remoting.

I think having verbose output for both the Invoke-Command cmdlet and the command itself is sane default behaviour. If someone wants verbosity only from Invoke-Command itself and not the command, they can set $VerbosePreference or pass the -Verbose:$false switch to the commands explicitly in the command scope or by using a similar workaround explained above.

I have to support this idea as well: Invoke-Command should definitely pass it's own -Verbose parameter to the script it's executing. I've tried every workaround and they all suck. Can't see this breaking anything.

+1

This seems more like a bug than a feature. Users expect the CmdletBinding properties to propogate through an Invoike-Command - any chance they will in the near future?

Here is a related RFC.

Was this page helpful?
0 / 5 - 0 ratings