Use PowerShell

PowerShell Version 3 introduces the concept of Default Parameter Values.

This allows you to specify a value for one or more parameters for one or more commands.

To implement this, you need to populate a new hashtable – $PSDefaultParameterValues

That Description is Not Helpful

Let’s look at some examples –

First off, we can specify the value for a parameter for a specific command.  The pattern used for the hashtable entries is “NameOfCommand:NameOfParameter” = “ValueOfParameter”.

(I’m stealing some of these examples from the samples provided in CTP1.)

$PSDefaultParameterValues = @{"Get-Process:Name"="powershell"}

Get-Process

Get-Process e*

With that set, every time we run Get-Process and do not specify the Name parameter, the PowerShell runtime will stick “powershell” in for that value.  A specified parameter will always override a default value.

Let’s go the other way and, instead of specifying one command, set a parameter value on all commands (that have that parameter.

$cred = Get-Credential mydomain\mydomainadminaccount

$PSDefaultParameterValues = @{"*:Credential" = $cred}

This would provide your $cred to any Credential parameter.

We can also use wildcards to match multiple commands.

$PSDefaultParameterValues = @{"*-AD*:Server" = 'MyDomainController'}

This would provide a default value to the Server parameter for any command whose noun started with AD (like everything in the ActiveDirectory module.

Since this is a hashtable, it can hold many different mappings –

$PSDefaultParameterValues = @{

  "*:Credential" = $cred

  "Get-Process:Name"="powershell"

  "*-AD*:Server" = 'MyDomainController'

}

To turn off DefaultParameterValues (without removing everything you have set up), you can set a key “Disabled” equal to $true.

$PSDefaultParameterValues = @{"Disabled" = $true}

This concludes our brief look at DefaultParameterValues for today.

Go grab Version 3 CTP2 and give it a whirl…

PowerShell V3 includes a new “feature” – Auto-loading of modules.

What Does It Do?

Module discovery has been updated to make the exported commands for modules that are not loaded visible in a PowerShell session.

In Version 2, if you run Get-Module on a module that is not loaded but in your PSModulePath, you’ll get some metadata about the module, but nothing about the ExportedFunctions, ExportedCmdlets, ExportedAliases, or ExportedVariables. 

Version 3 changes this, allowing Get-Module to retrieve information on all the exported features of the module.

This enables tab completion to complete the names of commands from modules that are not loaded.  It also provides information to the PowerShell runtime on where to get the command information from, if the module is not loaded.

So, in Version 3, if you run a command from a module that is not loaded, the runtime will search your PSModulePath for the first command that it can find that matches that name and load the module that command is in for you.

I’m Not Sold

I really don’t care for this feature.  I like to be in control of what module I import.  The order in which modules are automatically imported depends on your PSModulePath.  You don’t get to pick what the order is…  User specific PSModulePath entries are first, then machine specific PSModulePath entries.  This can cause a host of unexpected problems when there are command name collisions.

For example, the new Hyper-V cmdlets for Windows 8 cannot manage down-level Hyper-V machines, so you might need James O’Neil’s Hyper-V module from Codeplex.  Both modules have Get-VM.  Since James’ module will be in my user PSModulePath (most likely), unless I specifically load the Windows 8 Hyper-V module, running Get-VM will always load James’ module.