Weekend Scripter: Exploring PowerShell Modules
Summary: Use Windows PowerShell to explore Windows PowerShell modules.
Microsoft Scripting Guy, Ed Wilson, is here. One of the things I really, really, really like about Windows PowerShell is the fact that it is self-discoverable. I mean, I can use Windows PowerShell to explore Windows PowerShell and to learn about Windows PowerShell.
One of the neat features introduced in Windows PowerShell 3.0 was the automatic loading of Windows PowerShell modules. This was an essential feature given the explosion of Windows PowerShell modules that shipped with Windows 8 and Windows Server 2012. In Windows PowerShell 2.0 in Windows 7, I had a good feel for all the different modules, snap-ins, and the cmdlets. But with Windows PowerShell 3.0, the number of cmdlets, functions, and modules grew to the point where I am still finding new things I have not yet tried, and we are already into version 4.0 in Windows 8.1.
Opening the module to explore
The first thing that I like to do is to produce a list of available modules. To do that, I use the Get-Module cmdlet with the –ListAvailable switch as shown here (I like to use the alias gmo –l when I am doing this):
The command and the output from the command are shown here:
In the previous image, I can see that there are many modules located in different folders. I decide to select the path to the modules and to use the Split-Path cmdlet to view the parent folder. The first time I do it, the module folder itself returns. So I add an additional Split-Path command, and now I can see how modules reside in the various module locations. This is shown here:
PS C:\> Get-Module -ListAvailable | select path | Split-Path -Parent | Split-Path –Parent |
1 C:\Program Files\Share…
Most of the modules are in the default Windows PowerShell location. Only a few are in my Users location. One is in the strange SharePoint folder.
Looking at a specific module
I decide I want to look at a specific module: the wdac module. The first thing to do is to load the module. To do this, I use the Import-Module cmdlet (ipmo is the alias for this command). The command is shown here:
Nothing returns when I import the module. But if I use the –Verbose switch, I can see what the module does:
What’s in the module
When the module is imported, the Get-Module cmdlet returns information about the wdac module. The command is shown here:
And here is the output from this command:
The output is not extremely interesting. It does tell me that there is a manifest and the module is version 1.0. But there is more information available. To see that information, I pipe the output to the Format-List cmdlet (FL is an alias that I could use for Format-List):
Get-Module wdac | Format-List *
The command and the output from the command are shown in the image that follows:
There are some pretty interesting things available in the output. For instance, I can see the author of the module and the version of Windows PowerShell that is required. I see that the exported commands are functions, not cmdlets. I can list the functions by using dotted notation, as shown here:
PS C:\> (gmo wdac).ExportedFunctions
I also see that there is a format file. The path to the format file is:
PS C:\> (gmo wdac).ExportedFormatFiles
I can open that file in Notepad as shown here:
notepad (gmo wdac).ExportedFormatFiles
When the command runs, the following output appears:
Cool stuff. Take some time to explore other modules that may be interesting to you. Hey, it is the weekend (at least here in Charlotte, North Carolina), and weekends were made for Windows PowerShell exploration. Join me tomorrow when I kick off a poshpourri week.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at email@example.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy