Dreaming in PowerShell : Select-Object

Using Hash Tables and Select-Object

Tobias — Mon, 11 Jun 2012 02:12:00 GMT

If you don't like what PowerShell commands return to you, send it on to Select-Object! Select-Object is one of the most important cmdlets because it allows you to pick the columns (properties) you want to see. Check out these lines:

PS> Dir $env:windir
PS> Dir $env:windir | Select-Object -Property *
PS> Dir $env:windir | Select-Object -Property FullName
PS> Dir $env:windir | Select-Object -ExpandProperty FullName
PS> Dir $env:windir | Select-Object -ExpandProperty VersionInfo -ea SilentlyContinue

As you will observe, one identical command (listing all files in your windows folder) returns dramatically different information, thanks to Select-Object. This blog post is not really about Select-Object, though. It is about hash tables that you can feed into Select-Object to help you tailor results even more to your needs. Still, let's start with a quick refresher!

Select-Object - your Matrix Red Pill

If you have ever watched the movie "The Matrix" then you know what can happen when you swallow the red pill and not the blue one. Actually, Select-Object works like a red pill in the PowerShell ecosystem. Without it, you get back only partial results that look pretty much like classic console output. By sending results to Select-Object, you can choose the object properties (columns) you want to see, and if you submit a wildcard (*), you get back all available properties.

So what I tend to do is this: I send results to Select-Object -property *, get a good overview of the results, then pick the ones I need to create the custom report I need:

PS> Dir $env:windir | Select-Object -Property *
PS> Dir $env:windir | Select-Object -Property Mode, LastWriteTime, Name

Select-Object is pretty straight-forward to use and works with all object data returned by any cmdlet. However, there is one extra rule you should know to understand all the examples from above: when you pick only one object property, do not use the parameter -property. Use the parameter -expandProperty instead. -ExpandProperty replaces the result with the content of the object property you picked. Take a look at the difference:

PS> Dir $env:windir | Select-Object -Property Length
PS> Dir $env:windir | Select-Object -ExpandProperty Length

As you see, with -property the numeric column Length is displayed at the far right edge, with -expandProperty you just get back the numbers which is what you probably really wanted. If you only select one property, it simply does not make sense to have a single column header.

And there's more: when a column (property) contains another object or an array with multiple lines, the content is often discarded. With -ExpandProperty, however, you get back the complete content, and if the content is an object, the result is a new table with the columns now representing the object:

PS> Dir $env:windir | Select-Object -Property VersionInfo
PS> Dir $env:windir | Select-Object -ExpandProperty VersionInfo -ea 0

The only issue you can run into with -ExpandProperty is: if the property you picked is empty, you get an error because then, Select-Object does not know what to return. To work around this, you can add -ea 0 or -ErrorAction SilentlyContinue to your call to suppress these errors.

Now to the real thing I wanted to write about: Select-Object allows you to pick the columns but what if the column content isn't formatted the way you want, or what if the column header isn't perfect for you and you'd like to rename it. This is where hash tables enter the stage. Test yourself: Can you understand this piece of code?

$column = @{
Name = 'Length'
Expression = { '{0:0.0} MB' -f ($_.Length/1MB) }
}

Dir $env:windir | Select-Object Mode, LastWriteTime, $column, Name

Essentialy, what it does is: it reformats the column "Length" to show file length in MB rather than in bytes. If you digested this piece of code like a snap, then you are done! You already know about hash tables and you can use them now to reformat any column by submitting the hash table to Select-Object.

If you are rather confused, right on! Stick with me, so I can show you what the heck is going on here! The first thing we need to talk about are hash tables. What are they, and why would you need them?

Guerilla Session #1: Understanding Arrays

To understand hash tables, let's start with classic arrays. They are used to store multiple things in a variable.

Whenever you store something new in a classic array, your data is put into a "drawer" with a number, and to get back the data, you present that number in square brackets.

It's pretty straight forward:

PS> $ClassicArray = @() # create a new empty array

PS> $ClassicArray += 'my data'

PS> $ClassicArray += 'another piece of data'

PS> $ClassicArray += 12 # numeric data works, too

PS> $ClassicArray

my data

another piece of data

PS> $ClassicArray[0] # get first element

my data

PS> $ClassicArray[0,1] # get first and second element

my data

another piece of data

PS> $ClassicArray[-1] # get last element

Guerilla Session #2: Hash Tables

The ugly thing with arrays is that you need to know the exact position of the data you are after. All of the array "drawers" with their numbers aren't really very descriptive.

That's why there are hash tables. They basically work like arrays, except that you can call the drawers that store your data anything you like.

Let's rewrite the initial example to work with hash tables:

PS> $HashTable = @{} # create a new empty array

See? The close relationship between an array and a hash table is resembled by the way you create them. When you use parenthesis, you get an array. When you use braces, you get a hash table.

Now let's put some data into the brand new hash table. Since the "drawers" have no automatic dumb numbering system but instead can be labeled anything you like, you can pick a meaningful label (or "key") to store your information:

PS> $HashTable['FirstInfo'] = 'my data' # store data in the "drawer" FirstInfo

As it turns out, hash tables support both the array-like syntax (see above) and the object-property-syntax (see below):

PS> $HashTable.SecondInfo = 'another piece of data'

PS> $HashTable.ID = 12

Whenever you add a new key and value pair, it is stored inside the hash table, and when you dump the hash table, you get a list of keys and values:

PS> $HashTable

Name Value

---- -----

FirstInfo my data

ID 12

SecondInfo another piece of data

Of course, you can access individual information, too. In contrast to arrays, the order in which you added information to the hash table does not matter, anymore. All you need to do is to specify the key name you used when you stored the data:

PS> $HashTable['FirstInfo']

my data

You can also retrieve more than one element at a time:

PS> $HashTable['SecondInfo', 'ID']

another piece of data

And you can again use the object-property-syntax to get back data from your hash table:

PS> $HashTable.ID

PS> $HashTable.FirstInfo

Hello

So, hash tables are a great way of handing over information to someone else. If you and the recipient agree on the keys that you used to store the data, then the hash table can transport that data to the recipient. And that's exactly how PowerShell lets you use hash tables to do more with less code.

Wrapping It Up: Select-Object loves Hash Tables

Select-Object is a cmdlet that accepts hash tables. Not just any hash tables. It looks for two keys: Name and Expression. The value assigned to the key Name is then used for the column header. So this is what you use to change a column header you don't like. The value assigned to the key Expression must be some code (a script block in braces). It is executed for each element in a table and creates the column content. So here you can take the original object (which is represented by the variable $_) and reformat it to whatever you like.

Check your new PowerShell knowledge! Can you explain this code?

$column = @{
Name = 'MyColumn'
Expression = { 'Hello' }
}

Dir $env:windir | Select-Object Mode, LastWriteTime, $column, Name

Right! This adds a new column called "MyColumn", and its content is always "Hello". Does not make too much sense yet, but as you can see, the code block assigned to the key Expression is really executed multiple times, once for each object that was sent to Select-Object.

Here is a more sophisticated example. Check this one out:

$column = @{
    Name = 'Length'
    Expression = {
      if ($_.PSIsContainer) {
        '(folder)'
      } else {
        '{0:0.0} MB' -f ($_.Length/1MB)
      }
    }
}

Dir $env:windir | Select-Object Mode, LastWriteTime, $column, Name

This time, the code assigned to Expression is smart enough to differentiate between files and folder. If it's a folder, it has no Length property so some text is outputted.

Likewise, you can now access any - even nested - object properties and make them surface as new column in your reports. Here's another one:

$column = @{
    Name = 'Version'
    Expression = {
        $_.VersionInfo.FileVersion
    }
}

Dir $env:windir | Select-Object Mode, LastWriteTime, $column, Name

This one will add the file version number (if available). Again, it is completely up to you to enhance the code. As you'll see, some files have invalid version numbers, and this piece of code would return only correctly formatted version numbers that you can then use to sort or compare:

$column = @{
    Name = 'Version'
    Expression = {
        [System.Version]$_.VersionInfo.FileVersion.Replace(',','.').Split(' _')[0]
    }
}

Dir $env:windir | Select-Object Mode, LastWriteTime, $column, Name

What's Next?

The great thing about PowerShell is that you always get great rewards for investing some time and learning something new. Today, you learned what a hash table is and how you can feed it to Select-Object to tailor results to your needs. With this knowledge, you can do a lot more. Next time, I'll show you a couple more areas where you can use hash tables to unleash PowerShell.

See you soon!

Tobias

Microsoft MVP PowerShell Germany

P.S.
If you live in Germany or other parts of Europe and your company would like to set up a truly great PowerShell training, just contact me! I regularly train mid- to large-size companies. Trainings are always a blast with tons of real-world-examples and solutions. Here's how to get in touch with me: tobias.weltner@scriptinternals.de

Automatically Surfacing Subproperties

Tobias — Thu, 17 Feb 2011 00:22:00 GMT

Sometimes, the true information you are after is burried deep inside object models. For example, when you manage virtual machines with the VMWare cmdlets, Get-VM will get you only very sparse pieces of information. The real goodies are stored inside of subproperties (which was true for the MPEG3 module I created last week as well). Time to get a look at what is going on here (and how you can "move" hidden subproperties onto the stage and make them visible).

Just so you don't think today I was discussing a really geeky topic: what you learn today has tremendous real-life-value. For example, you are getting to see two pieces of code that seem to do the exact same thing, yet the one approach (which is used by a lot of folks out there) takes 40x more time to execute than the other (which is not so known).

[This kept spinning in my head: how come there can be such a huge performance difference? Turns out it was a caching effect. The true and real world speed benefit is about 2x, not 40x. Sorry if I got you excited . Fortunately, the performance gain was just an added benefit, the main story is about auto-adding script properties.]

To get a feeling for the problem, did you ever try and create a list of system DLLs and their versions? A plain dir won't get you far:

PS > dir $env:windir\system32\*.dll

Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 14.07.2009 03:39 158208 aaclient.dll
-a--- 14.07.2009 03:40 3745792 accessibilitycpl.dll
-a--- 14.07.2009 03:24 39424 ACCTRES.dll
(...)

This line does, though:

PS > dir $env:windir\system32\*.dll | Select-Object -ExpandProperty VersionInfo

ProductVersion FileVersion FileName
-------------- ----------- --------
6.1.7600.16385 6.1.7600.1638... C:\Windows\system32\aaclient.dll
6.1.7600.16385 6.1.7600.1638... C:\Windows\system32\accessibilitycpl.dll
6.1.7600.16385 6.1.7600.1638... C:\Windows\system32\ACCTRES.dll
6.1.7600.16385 6.1.7600.1638... C:\Windows\system32\acledit.dll
6.1.7600.16385 6.1.7600.1638... C:\Windows\system32\aclui.dll
6.1.7600.16385 6.1.7600.1638... C:\Windows\system32\acppage.dll
6.1.7600.16385 6.1.7600.1638... C:\Windows\system32\acproxy.dll
(...)

So what's going on here?

Either - Or: Select-Object can not always help

It turns out that file objects have a subproperty called VersionInfo. It contains the DLL versions we are after. To display that information, I used Select-Object with its -expandProperty parameter. This parameter tells PowerShell to replace the current object with the content of the property you specify. Thus I lost my original FileInfo object and in return got the VersionInfo object found in the property I specified.

Sounds confusing? Now, what it means is that Select-Object can only give you the content of one subproperty, and you pay for it by loosing all the properties in your original object. It is a simple trade-off.

Getting Dirty: Using Ad-Hoc Script Properties

In the previous example, the trade-off was ok. It is not always ok, though. Let's assume you need a report that includes filename, version, length and creationtime. How can you do that? After all, the information needed now comes partially from the FileInfo object and partially from the VersionInfo object stored inside of it.

Well, if your hair is on fire and you haven't got the time for a decent approach, use quick-and-dirty scripted properties. Here is an example:

PS > dir $env:windir\system32\*.dll |
Select-Object Name, { $_.VersionInfo.FileVersion }, Length, CreationTime

Name $_.VersionInfo.Fil Length CreationTime
eVersion
---- ------------------- ------ ------------
aaclient.dll 6.1.7600.16385 (... 158208 14.07.2009 02:17:30
accessibilitycpl... 6.1.7600.16385 (... 3745792 14.07.2009 02:34:00
ACCTRES.dll 6.1.7600.16385 (... 39424 14.07.2009 01:57:56
acledit.dll 6.1.7600.16385 (... 9216 14.07.2009 01:48:08
aclui.dll 6.1.7600.16385 (... 154112 14.07.2009 01:57:30

(...)

As you see, instead of specifying a column name (property name), you can also submit a script block and access the object subproperty you are after. That approach is ok, and you can even use a hash table if you want to get rid of the ugly column header:

PS > $version = @{name = 'Version'; expression={ $_.VersionInfo.FileVersion } }
PS > dir $env:windir\system32\*.dll | Select-Object Name, $version, Length, Crea
tionTime

Name Version Length CreationTime
---- ------- ------ ------------
aaclient.dll 6.1.7600.16385 (... 158208 14.07.2009 02:17:30
(...)

(Note that this only works when you define the hash table in one line. That's a PowerShell bug)

However, it's a lot of writing, especially with the hash tables. Even worse, Select-Object actually replaces your object and is creating a read-only copy. For reports, that is ok. If you want to keep the object methods, though, you may never use Select-Object. And if you want fast scripts, you should avoid Select-Object as well. Let's check out why and what to do about it next.

ScriptProperties to the Rescue

Rather than using Select-Object to add properties, you can also add script properties to the original object. In fact, that is something PowerShell uses by default for a lot of objects. Take a look at process objects returned by Get-Process:

PS > Get-Process | Get-Member -MemberType ScriptProperty

TypeName: System.Diagnostics.Process

Name MemberType Definition
---- ---------- ----------
Company ScriptProperty System.Object Company {get=$this.Mainmodule.Fi...
CPU ScriptProperty System.Object CPU {get=$this.TotalProcessorTim...
Description ScriptProperty System.Object Description {get=$this.Mainmodul...
FileVersion ScriptProperty System.Object FileVersion {get=$this.Mainmodul...
Path ScriptProperty System.Object Path {get=$this.Mainmodule.FileN...
Product ScriptProperty System.Object Product {get=$this.Mainmodule.Fi...
ProductVersion ScriptProperty System.Object ProductVersion {get=$this.Mainmo...

Here, PowerShell has made internal subproperties surface the top level by adding script properties. To see their actual code, try this:

PS > Get-Process | Get-Member -MemberType ScriptProperty | Select-Object -ExpandProperty Definition
System.Object Company {get=$this.Mainmodule.FileVersionInfo.CompanyName;}
System.Object CPU {get=$this.TotalProcessorTime.TotalSeconds;}
System.Object Description {get=$this.Mainmodule.FileVersionInfo.FileDescription;}
System.Object FileVersion {get=$this.Mainmodule.FileVersionInfo.FileVersion;}
System.Object Path {get=$this.Mainmodule.FileName;}
System.Object Product {get=$this.Mainmodule.FileVersionInfo.ProductName;}
System.Object ProductVersion {get=$this.Mainmodule.FileVersionInfo.ProductVersion;}

Note the use of -expandProperty again? Whenever PowerShell truncates your output, use it to pick the contents of the column you are interested in, and you get that information without truncation. Using Select-Object is not a bad thing, it is very useful in many scenarios. It is just not the best way to add new properties to objects as you'll see in a sec.

Creating New ScriptProperties With Add-Member

To add version information to file objects without changing the objects, you can add this property using Add-Member. Try this:

PS > dir $env:windir\system32\*.dll | Add-Member -MemberType ScriptProperty -Nam
e Version -Value { $this.VersionInfo.FileVersion } -PassThru | Select-Object Nam
e, Version, Length, CreationTime

Name Version Length CreationTime
---- ------- ------ ------------
aaclient.dll 6.1.7600.16385 (... 158208 14.07.2009 02:17:30
accessibilitycpl... 6.1.7600.16385 (... 3745792 14.07.2009 02:34:00
ACCTRES.dll 6.1.7600.16385 (... 39424 14.07.2009 01:57:56
(...)

Here I used Add-Member inside the pipeline to add the script property to the file objects returned by dir. I used the very same script block that I used with Select-Object except for one major difference: when you work with scriptproperties, replace $_ by $this.

The result seems to be just the same, so what is the difference compared to using Select-Object with hashtables and scripted properties?

Huge Performance Benefit: It is much faster. My approach with Select-Object ran 41 seconds.[and the SECOND time I ran it, it ran 3 seconds, so there is a caching effect here]. This approach with Add-Member just takes 1 second. Thats because Select-Object always has to copy the entire object which is a very expensive and ressource-hungry task. Add-Member just leaves the object as-is, and just attaches the new property to it.
Methods: For the same reasons, you keep the original objects and all the methods contained in them. Select-Object removes all methods and disconnects the copied object from the real object as well, so any changes to any properties will not do anything to the underlying object anymore.

Add-SubProps - Enjoy and Automate!

So you now know there can be tons of useful information in subproperties, and you should use Add-Member to make these properties visible. But... isn't that a bit too hard? Too much code, too much to remember? Right. That's why I created a function called Add-SubProps.

All you do is pipe your objects to it and specify the subproperty you would like to append. You can do that multiple times if you want and add the properties of a number of subobjects. It is all automated for you, and it is fast. It even creates read/write ScriptProperties for properties that are writeable. Here is what you can do with this function:

PS > dir $env:windir\system32\*.dll | Add-SubProps VersionInfo | Select-Object Name, ProductVersion, OriginalFileName, FileDescription

Name ProductVersion OriginalFilename FileDescription
---- -------------- ---------------- ---------------
aaclient.dll 6.1.7600.16385 aaclient.dll.mui Client für Zugri...
accessibilitycpl... 6.1.7600.16385 AccessibilityCpl... Systemsteuerung ...
ACCTRES.dll 6.1.7600.16385 ACCTRES.DLL.MUI Microsoft Intern...
acledit.dll 6.1.7600.16385 acledit.dll.mui Zugriffssteuerun...
aclui.dll 6.1.7600.16385 aclui.dll.mui Sicherheitsdeskr...
acppage.dll 6.1.7600.16385 acppage.dll.mui Shellerweiterung...
(...)

Now isn't that cool? Simply by piping file objects to Add-SubProps, I was able to access all the additional properties usually only found in the VersionInfo property.

Here is the Add-SubProps function (you can download it here):

function Add-SubProps {
param(
$prefix,
[Parameter(ValueFromPipeline=$true)]
$object
)

process {
# Add tag subobject properties:
$props = $object.$prefix | Get-Member -MemberType Property
$props | ForEach-Object {
$propname = $_.name
$writeable = $_.Definition -like '*{get;set;}*'
$getter = [ScriptBlock]::Create(('$this.{0}.{1}' -f $prefix,$propname))
if ($writeable) {
$setter = [ScriptBlock]::Create(('param(${1}) $this.{0}.{1} = ${1}' -f $prefix,$propname))
try {
$object = $object | Add-Member -MemberType ScriptProperty -Name $propname -Value $getter -SecondValue $setter -ea Stop -passthru
} catch {}
} else {
try {
$object = $object | Add-Member -MemberType ScriptProperty -Name $propname -Value $getter -ea Stop -passthru
} catch {}
}
}
$object
}´
}

If you read my post about reading and writing MPEG3 tags, you now know how the module magic was done. The module loaded the DLL that made the functionality available, and then Add-SubProps was used to compose the MPEG3 media objects with all their rich information. Since Add-SubProps leaves the original object untouched and adds read/write script properties, you were able to not just only read audio and video tags, but also change them and save them.

Add-SubProps is extremely valuable as you will see. For example, when you manage virtual machines with VMWare, Get-VM gets you objects that keep the interesting parts of your virtual machines in objects found in subproperties. You can now easily make them visible. Hope you had fun, see you next week around...

Tobias

Microsoft MVP PowerShell Germany

XML Part 1: Playing with RSS Feeds and XML Content

Tobias Weltner — Sat, 17 Jan 2009 09:37:00 GMT

A lot of data these days is wrapped as XML, and up until now, handling XML data wasn't a piece of cake. PowerShell makes handling XML a lot easier. This is the first part of a little series about XML and PowerShell. We start with accessing XML documents and reading data.

Getting XML Data

Let's first look how PowerShell can lay hands on XML data. One way is to create a new and empty XML document:

$xml = New-Object XML

Next, you can use your new XML document to load XML data, either from a local file or from the Internet. Use the Load() method. Let's for example load the www.powershell.com RSS ticker:

PS> $a = New-Object XML
PS> $a.Load("http://powershell.com/cs/blogs/MainFeed.aspx")
PS> $a

xml                                   xml-stylesheet                       rss
---                                   --------------                       ---
                                                                           rss
PS>

As long as you have access to the Internet, these lines will download the RSS news ticker into $a as an XML document, and when you output $a, you see a number of properties.

Browsing XML Data

What exactly is their meaning? To find out, let's first save the downloaded RSS ticker to file using the built-in Save() method. Next, we take a look at the first lines in that XML document by reading the xml file using Get-Content and selecting only the first 3 lines using Select-Object -First:

PS> $a.save("$home\rssticker.xml")
PS> Get-Content $home\rssticker.xml | Select-Object -first 3
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="http://powershell.com/cs/utility/FeedStylesheets/rss.xsl" media="screen"
?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/sla
sh/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
>

As it turns out, the PowerShell xml document in $a returns the top XML nodes: xml, xml-stylesheet and rss. Diving into nested information inside an XML document is very easy because it works in pretty much the same way as with objects. So if you'd like to see all the nodes below the root node rss, you use the rss property:

PS> $a.rss


version : 2.0
dc      : http://purl.org/dc/elements/1.1/
slash   : http://purl.org/rss/1.0/modules/slash/
wfw     : http://wellformedweb.org/CommentAPI/
itunes  : http://www.itunes.com/dtds/podcast-1.0.dtd
channel : channel

PS>

Again, if you'd looked at the raw XML data, you would see that the RSS node has these children: version, dc, slash, wfw, itunes and channel. Most of these are attributes with pieces of information. Channel however is another parent node and has a bunch of children. To look at the children, again use this property name:

PS> $a.rss.channel
format-default : The member "Item" is already present.

Property Name Conflict - And A Simple Workaround

Bang! You get a red error message. You cannot list the children inside the channel parent node. This is a bug, or rather, a conceptional weakness in design.

If you look at the raw XML data, you will see that the channel node contains a bunch of item nodes, and these item nodes are the ones with the interesting stuff: the feed messages. Unfortunately, the XML document object already has its own item property. The moment PowerShell tries to add the item property for the item children, you get the error message. An object cannot have two properties with the same name.

And here is the workaround: work in "blind" mode and just assume the children elements are named "item" (or whatever the error message indicates):

PS> $a.rss.channel.item


title       : Group Policy Cmdlets in Windows 7
link        : http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/16/group-policy-cmdlets-in
              -windows-7.aspx
pubDate     : Sat, 17 Jan 2009 04:46:08 GMT
guid        : guid
creator     : Windows PowerShell Blog
comments    : 0
description : Lilia Gutnik has posted a blog entry HERE showing an example of the Windows 7 Group Policy cmdlet
              s.&#160; Check it out. &#160; Experiment!&#160; Enjoy!&#160; Engage! Jeffrey Snover [MSFT] Window
              s Management Partner Architect Visit the Windows PowerShell Team blog at:&#160;&#160;&#160; http:
              //blogs.msdn.com/PowerShell Visit the Windows PowerShell ScriptCenter at:&#160; http://www.micros
              oft.com/technet Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/a
              rchive/2009/01/16/group-policy-cmdlets-in-windows-7.aspx">read more</a>)<img src="http://powershe
              ll.com/cs/aggbug.aspx?PostID=899" width="1" height="1">

title       : Jeffrey Snover and Bruce Payette on the PowerScripting Podcast
link        : http://powershell.com/cs/blogs/under-the-stairs/archive/2009/01/16/jeffrey-snover-and-bruce-payet
              te-on-the-powerscripting-podcast.aspx
pubDate     : Fri, 16 Jan 2009 14:35:00 GMT
guid        : guid
creator     : Under The Stairs
comments    : 0
description : I love downloading podcasts to my Zune and listening to them as I travel. I ve got a bit of a bac
              klog, but one I ve just downloaded and will be listening to shortly (possibly tomorrow as I head
              from Milan back to London) is the PowerScripting Podcast Read More......(<a href="http://powershe
              ll.com/cs/blogs/under-the-stairs/archive/2009/01/16/jeffrey-snover-and-bruce-payette-on-the-power
              scripting-podcast.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=898"
              width="1" height="1">
category    : {category, category}

title       : How To Make Your Own Module Repository
link        : http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/16/how-to-make-your-own-mo
              dule-repository.aspx
pubDate     : Fri, 16 Jan 2009 08:52:13 GMT
guid        : guid
creator     : Windows PowerShell Blog
comments    : 0
description : Andy Schneider (from Get-PowerShell.com ) recently asked me how he could make sure that everyone
              at Avanade could get a consistent set of modules. I run into a somewhat similar problem here at M
              icrosoft, where I want to take scripts I&#39;ve built to work with internal applications and make
               them easy for people to use, even if they&#39;re not already using PowerShell. I don&#39;t want
              the scripts to Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/ar
              chive/2009/01/16/how-to-make-your-own-module-repository.aspx">read more</a>)<img src="http://powe
              rshell.com/cs/aggbug.aspx?PostID=895" width="1" height="1">
category    : {category, category}


(...)

Now you get to the good stuff! These are the headlines you're after.

Using The PowerShell Pipeline

You just learned that you can access any RSS feed in the world by loading it into a new and empty XML document.

Since RSS feeds are XML documents and adhere to a defined format, you can always list all RSS messages by looking at the RSS.Channel.Item property. This returns all raw data contained in the individual RSS items. From here, simply use PowerShell Pipeline tricks to filter what you are looking for.

First, I'd like to filter the information. I only want to see the blog entry title and the link. Easy: use Format-Table:

PS> $a = New-Object XML
PS> $a.Load("http://powershell.com/cs/blogs/MainFeed.aspx")
PS> $a.rss.channel.item | Format-Table Title, Link

title                                                   link
-----                                                   ----
Group Policy Cmdlets in Windows 7                       http://powershell.com/cs/blogs/windows-powershell-te...
Jeffrey Snover and Bruce Payette on the PowerScripti... http://powershell.com/cs/blogs/under-the-stairs/arch...
How To Make Your Own Module Repository                  http://powershell.com/cs/blogs/windows-powershell-te...
Please Join Me for a Power Scripting Podcast Tonight... http://powershell.com/cs/blogs/windows-powershell-te...
Running PowerShell Scripts via Email                    http://powershell.com/cs/blogs/under-the-stairs/arch...
Date and Time in PowerShell (and WMI)                   http://powershell.com/cs/blogs/under-the-stairs/arch...
Date and Time in PowerShell                             http://powershell.com/cs/blogs/powershell-scripts/ar...
Windows 7 Troubleshooting                               http://powershell.com/cs/blogs/windows-powershell-te...
Podcast Discussing WSMAN 1/14/2008                      http://powershell.com/cs/blogs/windows-powershell-te...
Get-UpTime.ps1                                          http://powershell.com/cs/blogs/powershell-scripts/ar...
Interactive remoting in CTP3                            http://powershell.com/cs/blogs/windows-powershell-te...
How to copy colorized script from PowerShell ISE        http://powershell.com/cs/blogs/windows-powershell-te...
Please Give Us Feedback                                 http://powershell.com/cs/blogs/windows-powershell-te...
Blogging in 2008                                        http://powershell.com/cs/blogs/under-the-stairs/arch...
V2 Blog Entries                                         http://powershell.com/cs/blogs/windows-powershell-te...
Copy console screen to system clipboard                 http://powershell.com/cs/blogs/windows-powershell-te...
Get-Screensaver.ps1                                     http://powershell.com/cs/blogs/powershell-scripts/ar...
Colorized capture of console screen in HTML and RTF.    http://powershell.com/cs/blogs/windows-powershell-te...
Finding a URL For File Transfer Cmdlets                 http://powershell.com/cs/blogs/windows-powershell-te...
Transferring (Large) Files Using BITs                   http://powershell.com/cs/blogs/windows-powershell-te...
Test-PSCmdlet                                           http://powershell.com/cs/blogs/windows-powershell-te...
Capture console screen                                  http://powershell.com/cs/blogs/windows-powershell-te...
Get-Hash2.ps1                                           http://powershell.com/cs/blogs/powershell-scripts/ar...
PowerShell as Inventory Tool                            http://powershell.com/cs/blogs/windows-powershell-te...
Windows 7 Beta Has Arrived   But Not For Everyone       http://powershell.com/cs/blogs/under-the-stairs/arch...

Next, I only want the top 5 entries, and I do not want the link to be cut off. So I insert a Select-Object -First (remember, the Format cmdlets always have to be the last element in your pipeline), and I add a -wrap parameter to Format-Table:

PS> $a.rss.channel.item | Select-Object -first 5 | Format-Table Title, Link -wrap

title                                                   link
-----                                                   ----
Group Policy Cmdlets in Windows 7                       http://powershell.com/cs/blogs/windows-powershell-team/
                                                        archive/2009/01/16/group-policy-cmdlets-in-windows-7.as
                                                        px
Jeffrey Snover and Bruce Payette on the PowerScripting  http://powershell.com/cs/blogs/under-the-stairs/archive
Podcast                                                 /2009/01/16/jeffrey-snover-and-bruce-payette-on-the-pow
                                                        erscripting-podcast.aspx
How To Make Your Own Module Repository                  http://powershell.com/cs/blogs/windows-powershell-team/
                                                        archive/2009/01/16/how-to-make-your-own-module-reposito
                                                        ry.aspx
Please Join Me for a Power Scripting Podcast Tonight @  http://powershell.com/cs/blogs/windows-powershell-team/
9PM EST (6PM PST)                                       archive/2009/01/15/please-join-me-for-a-power-scripting
                                                        -podcast-tonight-9pm-est-6pm-pst.aspx
Running PowerShell Scripts via Email                    http://powershell.com/cs/blogs/under-the-stairs/archive
                                                        /2009/01/15/running-powershell-scripts-via-email.aspx

Can I filter based on topic, too? Sure thing. If you are interested in Windows 7, the upcoming new Windows client, and you'd like to see only blogs about Windows 7, then add a Where-Object into your pipeline.

Inside of it, the $_ placeholder represents the actual blog entry as it is running over the pipeline, and you then can check whether the title property contains one or more keywords.

PS> $a.rss.channel.item | Where-Object { $_.Title -like '*Windows 7*' } | Format-Table Title, Description

title                                                   description
-----                                                   -----------
Group Policy Cmdlets in Windows 7                       Lilia Gutnik has posted a blog entry HERE showing an...
Windows 7 Troubleshooting                               Windows 7 has a cool new extensible troubleshooting ...
Windows 7 Beta Has Arrived   But Not For Everyone       The Windows 7 and Windows Server 2008 R2 beta versio...

Maybe you'd like to output this as a nice report. Here is the thing to remember: Never use Format-... cmdlets when you plan to output results to sources other than the console. Use Select-Object instead. To create a simple HTML report, this is what I'd do:

PS> $a.rss.channel.item | Where-Object { $_.Title -like '*Windows 7*' } | Select-Object Title, Description | 
ConvertTo-Html | Out-File $home\report.htm; & "$home\report.htm"

This is what the resulting report looks like:

title	description
Group Policy Cmdlets in Windows 7	Lilia Gutnik has posted a blog entry HERE showing an example of the Windows 7 Group Policy cmdlets.  Check it out.   Experiment!  Enjoy!  Engage! Jeffrey Snover [MSFT] Windows Management Partner Architect Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/16/group-policy-cmdlets-in-windows-7.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=899" width="1" height="1">
Windows 7 Troubleshooting	Windows 7 has a cool new extensible troubleshooting framework which is entirely based on PowerShell scripts.  Rafael Rivera has written a very good step-by-step guide for how to author a Win7 Troubleshooting Pack HERE . Check it out. Experiment!  Enjoy!  Engage! Jeffrey Snover [MSFT] Windows Management Partner Architect Visit the Windows PowerShell Team blog at:    http Read More......(<a href="http://powershell.com/cs/blogs/windows-powershell-team/archive/2009/01/14/windows-7-troubleshooting.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=880" width="1" height="1">
Windows 7 Beta Has Arrived – But Not For Everyone	The Windows 7 and Windows Server 2008 R2 beta versions were released this week. I got the ISOs myself during the week, and finished off today loading R2, Win7 Ultimate and WIn7 Home Premium as VMware virtual machines. But it looks like Microsoft has totally Read More......(<a href="http://powershell.com/cs/blogs/under-the-stairs/archive/2009/01/10/windows-7-beta-has-arrived-but-not-for-everyone.aspx">read more</a>)<img src="http://powershell.com/cs/aggbug.aspx?PostID=848" width="1" height="1">

Admittedly, the HTML report does not really look very stylish, but you could change that as well:

PS> $head = '<style> BODY{font-family:Verdana; background-color:lightblue;} TABLE{border-width: 1px;border-style
: solid;border-color: black;border-collapse: collapse;} TH{font-size:1.3em; border-width: 1px;padding: 2px;borde
r-style: solid;border-color: black;background-color:#FFCCCC} TD{border-width: 1px;padding: 2px;border-style: sol
id;border-color: black;background-color:yellow}</style>'
PS> $title = "My Report"
PS> $body = "<H1>New Windows 7 + PowerShell Blogs</H1>"
PS> $a.rss.channel.item | Where-Object { $_.Title -like '*Windows 7*' } | Select-Object Title, Description | 
ConvertTo-Html -title $title -head $head -body $body    | Out-File $home\report.htm; & "$home\report.htm"

Here is more brainfood on colorizing HTML reports: http://powershell.com/cs/blogs/tips/archive/2009/01/05/outputting-html-reports.aspx

Convert Text to XML

To wrap up this first part of our XML series, let's finally look at two more ways to read XML data into PowerShell. At the beginning of this article, we loaded the XML via Internet into an empty XML object. From here, you can save the XML as file. Using the same Load() method, you can also load XML data from an XML file:

PS> $a = New-Object XML
PS> $a.Load("http://powershell.com/cs/blogs/MainFeed.aspx")
PS> $a.Save("$home\myxml.xml")
PS>
PS> $b = New-Object XML
PS> $b.Load("$home\myxml.xml")
PS> $b

xml                                   xml-stylesheet                       rss
---                                   --------------                       ---
                                                                           rss

So the second approach is to load a file-based XML into an empty XML object. The third approach uses type conversion. You read in XML data as plain text, then convert this into the XML data type.

Remember two things here: Type conversion works by writing the type (in square brackets) in front of the data you want to convert, and second: use parenthesis around Get-Content because you do not want to convert the Get-Content cmdlet of course but rather its result.

PS> $c = [xml] (Get-Content $home\myxml.xml)
PS> $c

xml                                   xml-stylesheet                       rss
---                                   --------------                       ---
                                                                           rss

Next Steps...

Next time, we will create our own XML documents, look at some more advanced data analysis and update and change XML data in an XML file. Make sure to check back next week! Which you now by the way could automate, too. Simply use the RSS ticker in the examples above to check for new blog entries on powershell.com!

Cheers and a great and relaxing weekend to you,
and don't forget to check out PowerShell Plus! It's great and simply one of the best ways to learn PowerShell!

-Tobias

MVP Windows PowerShell