This past Tuesday, I was privileged to speak at the Cleveland C#/VB.NET SIG on extending PowerShell. Since I knew that my audience wasn’t necessarily familiar with PowerShell (except a few), I spent the first half of the session introducing PowerShell and many of its key concepts with the help of a custom module, built specifically for this presentation.
The only PowerPoint slides that were used were Sam’s slides to announce upcoming user group meetings, events, and sponsor information. Otherwise, I chose not to use PowerPoint and took a page from my friend Matt Casto‘s book, using a technology to present the technology. (He had done a presentation on Silverlight at a Central Ohio Day of .NET using a Silverlight app to show “slides”. I thought this was a cool technique and figured I could use PowerShell to explain PowerShell.)
The custom module is a manifest module, as I generated a PSD1 file for the module. However, if you remove the PSD1 file, the module is then considered to be a script module, as was covered in the talk.
To give you some background, my $profile has the following setup:
Set-Alias alias Set-Alias
$PSModulePath = $env:psmodulepath
I use the alias example because it irritates me to no end that there are some Linux commands that are already aliased, but the obvious alias alias was left out.
The function Get-Home is referenced in one of my help files. There’s a story behind this one. Again, this goes back to my Linux/Unix background. While Matt and I were working on the book, he had an example of a custom function that would get the user’s home directory. He used some long, convoluted path after the cd command. Of course, I had to come back and explain to him what the ~ meant, as I used to type cd ~ a lot when I spent time in the Unix labs on campus in my college days. It wouldn’t be until later on, as I was preparing for this talk, that I found the ~ explained in a PowerShell help file. (It’s in the help text for Resolve-Path.)
Finally, I included the $PSModulePath variable for two reasons. One, there’s improper documentation that this variable is a pre-defined variable. There are community comments that point out this flaw. The other reason is so that I can use the environment variables as a good segue into the providers topic.
I noted that I was not really going to get into covering creating custom providers, as there is a lot of detail behind that. However, if you want to talk providers, Oisin Grehan is a PowerShell provider master. He is also the guy behind the PowerShell Script Provider, to allow writing PowerShell providers in PowerShell scripting language and not necessarily in C#.
The other recommendation that was mentioned was to use the #PowerShell hashtag on Twitter, as there are many awesome PowerShell MVPs and notable people who work with it who are gratiously answering questions and helping as needed, providing direction for learning more on PowerShell.
You can download the custom ClevSIG2011 module here.
If you have PowerShell already installed, then here are the steps for using the module:
1. Extract the zip file into one of the Modules folders in $env:PSModulePath. Since this is unique to me, I put mine in my DocumentsWindowsPowerShellModules folder.
2. Start PowerShell (ISE or console).
3. Run the following command: Import-Module ClevSIG2011
4. Getting started with the module, run: Get-Help about_KeyTerms for more information.
The second half of my presentation involved creating custom cmdlets. In our book, I wrote about cmdlets to work with the Windows 7 Libraries feature – the feature that deals with Documents, Music, Video, Pictures, Contacts, and Downloads. The code that I used for that part will most likely be included in supplemental materials for our book. You can pre-order the Automating Microsoft® Windows Server 2008 R2 Administration with Windows® PowerShell 2.0 book through a variety of vendors.
I had a lot of fun presenting to such a lively crowd, and I especially enjoyed talking with others at Mavis Winkle’s afterwards! Thanks to all who came out for it!