Use PowerShell to Create Intelligent Default Values

Summary: Windows PowerShell 3.0 introduces the PSDefaultParameterValues automatic variable, which permits creating custom default values.

Microsoft Scripting Guy, Ed Wilson, is here. Life is returning to normal—at least for this week. Next week, the Scripting Wife and I head north where I will be speaking at the Central Ohio PowerShell User Group (COPUG) on October 2, 2012. There are only a few tickets left for this free event, so if you are in the area and you want to catch up with us while we are there, you will need to register soon.

For today, I am sitting at my desk, checking email, and sipping a nice cup of Gunpowder Green Tea with a bit of lemon grass and a cinnamon stick for sweetness. Outside, there has been a cool steady drizzle of rain, and the wind has been whistling through the trees causing the leaves to rustle like crinolines on prom night.

Finding custom Windows PowerShell default values

In Windows PowerShell 3.0, a new automatic variable exists called PSDefaultParameterValues. This variable is shown here.

PS C:\> Get-Variable PSDefaultParameterValues

Name                           Value

----                           -----

PSDefaultParameterValues       {}

As you can see, the value of the PSDefaultParameterValues automatic variable accepts an object. This information also appears in Get-Member.

PS C:\> Get-Variable PSDefaultParameterValues | Get-Member  -Name value

   TypeName: System.Management.Automation.PSVariable

Name  MemberType Definition

----  ---------- ----------

Value Property   System.Object Value {get;set;}

Note   Remember that when setting a value or retrieving a value for a variable, the dollar sign ($) identifies the variable. But when using cmdlets such as Get-Variable, Set-Variable, or New-Variable, the dollar sign does not come into play. This is because the dollar sign is not actually part of the variable name.

Setting custom Windows PowerShell default values

So what good is the PSDefaultParameterValues automatic variable? Suppose I have a cmdlet that I use on a regular basis, and every time I use the cmdlet, I am typing the same parameter values. A useful example of this might be if I use the Send-MailMessage cmdlet to send mail notifications from scripts—I would typically use the same SMTP server for each calling of the cmdlet. In fact, this scenario appears in about_Parameters_Default_Values in the Microsoft TechNet Library.

To set a default value for a cmdlet, I essentially use a hash table.

Note   If you have not noticed, hash tables are really important. To move beyond basic Windows PowerShell techniques, you need to know how to create a hash table. See this collection of Hey, Scripting Guy! Blogs for more information about creating and using hash tables.

The syntax to assign a new default value is shown here.

In the following example, I create a default value for the Name parameter of the Get-Process cmdlet. This permits me to quickly find information about the Explorer process.

$PSDefaultParameterValues = @{"Get-Process:name"="explorer"}

Now when I run the Get-Process cmdlet, it only returns information about the Explorer process. I can override this by using a wildcard character. This technique is shown here.

gps *

The commands and the output associated with the commands are shown in the image that follows.

If I open a new Windows PowerShell console, the new defaults do not apply. To change the default behavior of a cmdlet, function, or advanced function that happens every time I open the Windows PowerShell console or Windows PowerShell ISE, I need to add the command to my Windows PowerShell profile.

            Note   For more information about profiles, see this collection of Hey, Scripting Guy! Blogs.

That is all there is to creating and to using custom default values in Windows PowerShell 3.0. Join me tomorrow for more cool Windows PowerShell 3.0 stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy