You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Suggestion :: Write-Verbose Behaviour when packaged in a module #3106
When Write-Verbose is included in a function or cmdlet in a module file, it doesn't behave in the same way as it would had that function been written in the main script file. i.e.
# MyScript.ps1
[CmdletBinding()]
param()
functionInvoke-Demo {
[CmdletBinding()]
param ([Parameter()][string]$Message)
process {Write-Verbose$Message}
}
Invoke-Demo'This DOES show when I run ".\MyScript.ps1 -Verbose"'Write-Verbose'This DOES show when I run ".\MyScript.ps1 -Verbose"'
Behaves differently to:
# MyModule.psm1functionInvoke-Demo {
[CmdletBinding()]
param ([Parameter()][string]$Message)
process {Write-Verbose$Message}
}
# MyScript.ps1
[CmdletBinding()]
param()
Import-Module-Path '.\MyModule.psm1'-Force
Invoke-Demo'This does NOT show when I run ".\MyScript.ps1 -Verbose"'Write-Verbose'This DOES show when I run ".\MyScript.ps1 -Verbose"'
This seems counter intuitive, and overly complex to get write-verbose to function based on whether the script is being run with the verbose switch enabled.
Suggested Solution
Since there may be a design reason for this behaviour, it's likely best that any new behaviour be controlled explicitly. As such I'd suggest enabling Write-Verbose to function as desired by including a switch when importing the module; i.e.
Reacted by Adam Daniel, Joey Piccola, Francis Thérien, Cy Rossignol, Michael Klement, Tres Finocchiaro, Florian Carrier, rudolfwalter, Eduard Georgiev, zett42 and 1 more
It took a while to emerge, but this is actually the more fundamental issue discussed in #4568:
Inheritance of common parameters - not just -Verbose, but notably also -WhatIf - via advanced functions relies on implicitly set local preference variables:
A common parameter, such as -Verbose, passed to an advanced function is function-internally automatically translated into an equivalent local preference variable_, such as $VerbosePreference.
This inheritance mechanism ONLY works:
when invoking binary cmdlets, which do see and respect the local preference variable.
when calling scripts / other functions in the same module scope as the caller.
By contrast, a function from a different module cannot see the caller's local preference variable, due to how module scopes function fundamentally.
In short: the common-parameter inheritance mechanism is fundamentally broken for advanced functions across module scopes.
Activity
joeypiccola commentedon May 3, 2017
I hit this a few years back, was hoping it was figured out.
mklement0 commentedon Apr 7, 2018
It took a while to emerge, but this is actually the more fundamental issue discussed in #4568:
Inheritance of common parameters - not just
-Verbose, but notably also-WhatIf- via advanced functions relies on implicitly set local preference variables:A common parameter, such as
-Verbose, passed to an advanced function is function-internally automatically translated into an equivalent local preference variable_, such as$VerbosePreference.This inheritance mechanism ONLY works:
By contrast, a function from a different module cannot see the caller's local preference variable, due to how module scopes function fundamentally.
In short: the common-parameter inheritance mechanism is fundamentally broken for advanced functions across module scopes.
ThomasNieto commentedon Aug 18, 2023
Steven Bucher (@StevenBucher98) should this be closed as a duplicate/related to #4568?