{"id":4319,"date":"2015-04-02T11:00:13","date_gmt":"2015-04-02T15:00:13","guid":{"rendered":"http:\/\/jdhitsolutions.com\/blog\/?p=4319"},"modified":"2015-04-04T11:30:28","modified_gmt":"2015-04-04T15:30:28","slug":"powershell-blogging-week-supporting-whatif-and-confirm","status":"publish","type":"post","link":"https:\/\/jdhitsolutions.com\/blog\/powershell\/4319\/powershell-blogging-week-supporting-whatif-and-confirm\/","title":{"rendered":"PowerShell Blogging Week: Supporting WhatIf and Confirm"},"content":{"rendered":"

We hope you are enjoying this experiment in community blogging. In today's contribution I want to demonstrate how you can add support for WhatIf and Confirm to your advanced PowerShell functions. It is actually quite easy, especially if your function is simply calling other PowerShell commands that already support \u2013Whatif and \u2013Confirm. The recommended best practice is that if your function will do anything that changes something, it should support these parameters. Here's how.<\/p>\n

In your function you will need to use the cmdletbinding attribute and specify SupportsShouldProcess.<\/p>\n

[cmdletbinding(SupportsShouldProcess)]<\/code><\/pre>\n
Beginning with PowerShell 3.0 this is all you need but you will see scripters explicitly setting this to $True.<\/p>\n
[cmdletbinding(SupportsShouldProcess=$True)]<\/code><\/pre>\n
That's fine, although personally I find it redundant. If SupportsShouldProcess is listed then by default it is True. There is no need to explicitly set this to $False. Simply omit it. When you add this attribute, you will automatically get the \u2013WhatIf and \u2013Confirm parameters. The best part is that if your function is simply calling PowerShell cmdlets that already support \u2013WhatIf, they will automatically inherit this setting. Here's a sample function.<\/p>\n
#requires \u2013version 4.0\r\n\r\nFunction Remove-TempFile {\r\n[cmdletbinding(SupportsShouldProcess)]\r\n\r\nParam(\r\n[Parameter(Position=0)]\r\n[ValidateScript({Test-Path $_})]\r\n[string]$Path = $env:temp\r\n)\r\n\r\n#get last bootup time\r\n$LastBoot = (Get-CimInstance -ClassName Win32_OperatingSystem).LastBootUptime\r\nWrite-Verbose \"Finding all files in $path modified before $lastboot\"\r\n\r\n(Get-Childitem -path $path -File).Where({$_.lastWriteTime -le $lastboot}) | Remove-Item\r\n\r\n} #end function\r\n\r\n<\/pre>\n
The function deletes all files from the %TEMP% folder that have a last modified time older than the last boot up time. As you can see in the help, PowerShell added the necessary parameters.<\/p>\n
\"\"<\/p>\n
When I run the function with \u2013Whatif it is passed on to Remove-Item.<\/p>\n
\"\"<\/p>\n
It is really that easy. I also automatically get support for \u2013Confirm.<\/p>\n
\"\"<\/p>\n
Things gets a little trickier when you want to support WhatIf for a function where your commands don't natively recognize SupportsShouldProcess. This would be true of any .NET static method or even a command line tool you might be running, to name a few examples. To add your own support you need to invoke the built-in $PSCmdlet object and its ShouldProcess() method. Here's a simple example.<\/p>\n
Function Set-Folder {\r\n[cmdletbinding(SupportsShouldProcess)]\r\n\r\nParam(\r\n[Parameter(Position=0,\r\nValueFromPipeline,\r\nValueFromPipelineByPropertyName)]\r\n[Alias(\"pspath\")]\r\n[ValidateScript({Test-Path $_})]\r\n[string]$Path=\".\")\r\n\r\nProcess {\r\n$Path = (Resolve-Path -Path $Path).ProviderPath\r\nif ($PSCmdlet.ShouldProcess($Path)) {\r\n#do the action\r\n$Path.ToUpper()\r\n}\r\n} #Process\r\n\r\n} #end function\r\n\r\n<\/pre>\n
This function hypothetically is going to perform some action on a folder and I'm simply displaying the folder name in upper case. The important part is the If statement. This is the bare minimum that you need. If you specify \u2013WhatIf you'll be prompted.<\/p>\n
\"\"<\/p>\n
The operation will be the name of your script or function. The target is the ShouldProcess parameter value which in my example is the path. But you can provide more specific information by specifying ShouldProcess parameters for the target and action. Here's a revised function.<\/p>\n
Function Set-Folder2 {\r\n[cmdletbinding(SupportsShouldProcess)]\r\n\r\nParam(\r\n[Parameter(Position=0,\r\nValueFromPipeline,\r\nValueFromPipelineByPropertyName)]\r\n[Alias(\"pspath\")]\r\n[ValidateScript({Test-Path $_})]\r\n[string]$Path=\".\")\r\n\r\nProcess {\r\n$Path = (Resolve-Path -Path $Path).ProviderPath\r\nif ($PSCmdlet.ShouldProcess($Path,\"Updating\")) {\r\n#do the action\r\n$Path.ToUpper()\r\n}\r\n} #Process\r\n\r\n} #end function\r\n\r\n<\/pre>\n
\"\"<\/p>\n
You must have the code for ShouldProcess otherwise even if you set the cmdletbinding attribute, PowerShell won't know which commands need WhatIf. You can also have as many ShouldProcess statements as you need.<\/p>\n
When it comes to confirmation, things get a little trickier and it might depend on what you really need. As you saw above, any cmdlet that supports \u2013Confirm should automatically inherit the setting. This works because there is another cmdletbinding attribute called ConfirmImpact which has a default value of Medium. Other options are Low and High. My first function could also have been written like this:<\/p>\n
[cmdletbinding(SupportsShouldProcess,ConfirmImpact=\"medium \")]<\/code><\/pre>\n
Confirmation happens by comparing the value of ConfirmImpact with the built-in $ConfirmPreference variable which has a default value of High. If the value of $ConfirmPreference is equal to or greater than ConfirmImpact, PowerShell will prompt for confirmation. Let's test this out.<\/p>\n
Function Set-Folder6 {\r\n[cmdletbinding(SupportsShouldProcess,ConfirmImpact=\"High\")]\r\n\r\nParam(\r\n[Parameter(Position=0,\r\nValueFromPipeline,\r\nValueFromPipelineByPropertyName)]\r\n[Alias(\"pspath\")]\r\n[ValidateScript({Test-Path $_})]\r\n[string]$Path=\".\"\r\n)\r\nBegin {\r\nWrite-Verbose \"Starting $($MyInvocation.Mycommand)\"\r\n} #begin\r\n\r\nProcess {\r\n$Path = (Resolve-Path -Path $Path).ProviderPath\r\nWrite-Verbose \"Processing $path\"\r\nif ($PSCmdlet.ShouldProcess($Path,\"Updating\")) {\r\n#do the action\r\n$Path.ToUpper()\r\n} #ShouldProcess\r\n} #Process\r\n\r\nEnd {\r\nWrite-Verbose \"Ending $($MyInvocation.Mycommand)\"\r\n} #end\r\n\r\n} #end function\r\n\r\n<\/pre>\n
Notice that I am also using for WhatIf. In this function the ConfirmImpact is set to high which means PowerShell will always prompt.<\/p>\n
\"\"<\/p>\n
If I edit the function and change to ConfirmImpact to Medium or Low, then PowerShell will only confirm if I ask.<\/p>\n
\"\"<\/p>\n
You don't have to specify anything for cmdletbinding. If you know you always want confirmation you can do something like this:<\/p>\n
Function Set-Folder4 {\r\n[cmdletbinding()]\r\n\r\nParam(\r\n[Parameter(Position=0,\r\nValueFromPipeline,\r\nValueFromPipelineByPropertyName)]\r\n[Alias(\"pspath\")]\r\n[ValidateScript({Test-Path $_})]\r\n[string]$Path=\".\",\r\n[switch]$Force\r\n)\r\n\r\nProcess {\r\n$Path = (Resolve-Path -Path $Path).ProviderPath\r\nWrite-Verbose \"Processing $path\"\r\nif ($Force -OR $PSCmdlet.ShouldContinue(\"Do you want to continue modifying folder?\",$path)) {\r\n#do the action\r\n$Path.ToUpper()\r\n}\r\n} #Process\r\n\r\n} #end function\r\n\r\n<\/pre>\n
Notice the use of the ShouldContinue method. When I run this function, PowerShell will always prompt for confirmation.<\/p>\n
\"\"<\/p>\n
I also added a switch parameter called Force so that if it is specified, the user is not prompted for confirmation.<\/p>\n
\"\"<\/p>\n
The downside to this approach is that help doesn't show anything.<\/p>\n
\"\"<\/p>\n
Perhaps in special cases this is what you want. Personally, I think you are better off using the cmdletbinding attributes as I did for my Set-Folder6 example.<\/p>\n
Adding support for WhatIf and Confirm doesn't take much effort and it will take your advanced function to the next level.<\/p>\n
\n
This post is part of the PowerShell Blogging Week series on Windows PowerShell Advanced Functions, a series of coordinated posts designed to provide a comprehensive view of a particular topic.<\/p>\n
Other articles in this series:<\/p>\n