Recently I did an online presentation on ISE Addons. As I was preparing for the talk one thing led to another, as they usually do when I’m working in PowerShell, and before I knew it I had a new add-on for the PowerShell ISE. This addon creates a menu for all of the modules in your module path.
The module looks at the $env:PSModulePath environmental variable and creates a submenu for each module. I came up with a nice two level Write-Progress command because at least on my desktop I have a lot of modules.
My script creates a sub menu for each discovered module.
You can import the module directly from the menu, and when you do, my module dynamically updates the menu with options to look at all the commands in the module and to remove it.
The module menu uses Out-Gridview quite a bit to keep things graphical, but it is view only. However, I added a nice module summary.
To try this out, download ModuleMenu.zip and extract to your modules folder. Then in the ISE, import module ModuleMenu. Everything is contained in a single .psm1 file which you can edit directly from the menu! Perhaps you might not need the module, but it offers some nice examples of creating ISE add-on menu items. Once PowerShell v3 is released, much of this will probably be irrelevant. I’ll worry about that later.
Over the last year I’ve posted functions I’ve written to extend the Windows PowerShell ISE. I have finally pulled everything together into a module I’m calling the ISE Scripting Geek. Download and extract the zip file (below) to your modules folder. You should end up with a path like ‘C:\Users\Jeff\Documents\WindowsPowerShell\Modules\ISEScriptingGeek’.
In the ISE, import the module:
Or do as I did and add it to your Powershell ISE profile script. The module will add an ISE Scripting Geek menu add on.
Here you will find my tools for printing a script, signing a script, converting aliases to commands (and vice versa) and a few other goodies. I’ve also included my function to keep track of most recently used scripts. If you don’t want to use some of the tools, edit the psm1 file and comment out what you don’t want. If there’s something you’d like to see, let me know. No promises but I might have something stashed away.
[shameless plug] If you want to look cool as well check out www.ScriptingGeek.com
UPDATE: A revised version of this module for PowerShell 4.0 and later is now available at http://bit.ly/14aGnLq
For last week’s Friday Fun, I posted a PowerShell script to create a traditional Bingo card. I hoped you would also learn a few PowerShell concepts along the way. This week I’ve taken this to the next level, and have a complete module that not only creates the card but also let’s you play the game. There’s a lot going on here with regular expressions, custom view PS1XML files, variable scope and more. Continue reading
More and more, you’re seeing members of the Windows PowerShell community package their contributions into modules, myself included. Although you’ll probably still see a lot of individual functions because it is often easier to demonstrate or educate. I received a comment on my Weather module that I thought merited a complete post, since I expect there are many administrators still new enough to PowerShell and especially PowerShell 2.0. The question is basically, “I’ve downloaded a module. Now what?”
One major benefit of a module over snapins, is that modules can be deployed with a simple file copy. There is no installation, registration, or the like. Extract the files and PowerShell can use them. But where? Windows PowerShell 2.0 will examine a system environmental variable called %PSMODULEPATH%
The path you see here is for modules that would apply to any user of this computer. Open a PowerShell prompt and look at the variable and you will also see a path that is set for the current user.
PS C:\> $env:psmodulepath
The Modules directory does not exist by default, nor does WindowsPowerShell for that matter, so you might need to create them. Underneath the Modules directory you will have a folder for each module. Thus, you would extract my weather module to a folder called JH-Weather. In that folder are all the module files.
For the most part, these should be the only paths you need. But if you would like to specify an additional module path, you can modify the environmental variable by appending a new path.
PS C:\> $env:psmodulepath=$env:psmodulepath + “;c:\scripts”
PS C:\> $env:psmodulepath.split(“;”)
Now, PowerShell will also search C:\Scripts for any modules. HOWEVER..this modification is only for the current PowerShell session. If I open a new PowerShell session, I’ll be back to the same path. If you always need this path, then add the modification command to your PowerShell profile script. Make sure you make the change in your profile before you attempt to import any modules from the new folder.
The Get-Module cmdlet will show all currently loaded modules. If you want to see all the available modules use the -ListAvailable parameter.
PS C:\> Get-Module -ListAvailable | Sort Name | Select Name
When I want to use a module I import it into my session.
PS C:\> Import-Module WebAdministration
Use Get-Command to see the module contents.
Creating modules is a completely different topic for another day, but I hope this has helped get you started in the right direction regarding what to do with modules. If not, let me know. There is also a help topic, About_Modules you should read. Don Jones and I also cover modules in Windows PowerShell 2.0: TFM
I first wrote a Windows PowerShell function several years ago to retrieve weather information via Yahoo’s weather service. I’ve been itching to rewrite it and finally found some time over the weekend. Turns out it’s a good thing I did because the method I had been using to query the Yahoo web service has been deprecated. My original version relied on a zip or postal code. But now Yahoo relies on a WOEID or “Where on Earth ID”.
The underlying structure of my Get-Weather function hasn’t changed much. Using the Webclient object I query the Yahoo web service, retrieve an XML document and parse it. I then write a custom object to the pipeline.
PS C:\> get-weather 12762649
Date : Mon, 26 Jul 2010 7:54 am EDT
Location : Jamesville, NY
Temperature : 67 F
Condition : Partly Cloudy
ForecastCondition : Sunny
ForecastLow : 60 F
ForecastHigh : 80 F
My new version includes a lot more information. The function’s default is this basic view. However you can also specify Extended or All. I defined a set or properties and then pipe my custom object to Select-Object specifying the appropriate property set.
Since the new version requires a WOEID, you’re probably wondering how to find it. One way is to go to http://weather.yahoo.com/ and enter in your zip code or location in the search box. Your WOEID will be the number at the end of the url that is returned. Or you can use the Get-Woied function. This function takes some sort of search and returns a simple object, including the WOEID.
PS C:\> get-woeid “Detroit,MI”
Country : US
Region : Michigan
Locale : Detroit
WOEID : 2391585
PS C:\> get-woeid 68132
Country : US
Region : Nebraska
Postal : 68132
Locale : Omaha
WOEID : 12787550
You can even use the two in a pipeline.
PS C:\> get-woeid 68132 | get-weather -extended
Date : Mon, 26 Jul 2010 6:52 am CDT
Location : Omaha, NE
Temperature : 70 F
Condition : Partly Cloudy
ForecastCondition : Partly Cloudy
ForecastLow : 72 F
ForecastHigh : 88 F
WindChill : 70 F
WindSpeed : 5 mph
Humidity : 84%
Barometer : 30.07 in and steady
Visibility : 10 mi
Tomorrow : Tue 27 Jul 2010 Mostly Sunny Low 74F: High: 94F
I’ve put everything together in a module, JH-Weather. The module also defines aliases of gwid and gw for Get-Woeid and Get-Weather, respectively. I have some other ideas for the module so stay tuned for future releases. In the mean time you can download a zip file with the module here.