Last week I managed to write few short posts for PowerShell Magazine. It was whole series about XPath. You can think of it as an extension to my earlier post about case-insensitive Select-Xml. And I can’t express enough how different (read: better) this experience was from writing anything for my own blog. Having second pair of eyes (with healthy amount of criticism) made huge difference in the final “product”.
You probably seen this a lot: new Foreach-Object and Where-Object syntax without script block is something people blogged about a lot. Some people love it, some hate it, some see it as a source of confusion for new-comers. I personally love it and I try to use it whenever possible (but only when working in interactive shell). You will see most of time new syntax works great, but it fails badly when used in more complex filters. I would like to show you how it can be used in combination with old syntax to simplify your code even in more complex situations.
When working with regular expressions in PowerShell to check if certain string matches a pattern we can use it in both directions: to match or not match it (with –match and –notmatch operators). That’s very handy and it saves us a lot of time, because we don’t have to come up with regular expression that would do it for us. But there are certain situations where operators are not used.
PowerShell is not case sensitive (most of the time). There are two situation when it is: you explicitly request it (e.g. using operators like –cmatch) or we depend on something where there is no easy way to turn it off. Select-Xml is using XPath and falls in the second category. Whenever I need to query large XML file I prefer to start with more general queries, and there is very few things more frustrating than being forced to remember case of e.g. attribute names. There are two options to go about it.
First of all we can do it easy way: change case of the whole string that defines XML, and be sure, that everything is either lower or upper case. Problem with this approach is the fact, that result we get back is different from original, and we are bit “stuck” with “broken” XML.
Second option is to use XPath own tools to get similar results, and has advantage of getting “proper” XML data back. Using Select-Xml also enables modifying XML and saving under different name.
Whenever I work with Active Directory and I want to use pretty complex LDAP Filter to search for objects I’m after I’m tempted to use line break here and there to make whole thing easier on eyes of future reviewer (even if the only person to read the code is me “few weeks later”).
If you use –split as often as I do you probably had occasional issue with understanding why certain splits work as expected, and some produce results different from what you anticipated. Recently one of MVPs, Oisin Grehan, shed some light on the reason why this is the case. I thought it might be worth sharing in case you’ve had this issue and you are pulling your hair trying to figure out what’s going on.
This is sixth and final part of the series. You can find outline of the whole series here. We already have OMI server up, running and accessible from outside and we have test Lin_Process implemented on it, with several properties and single method: Kill. Today we will build our own CDXML-based module that will surround remote CIM calls in cmdlet-like functions. This package won’t be auto-generated, I had no luck finding procedure to do that (truth be told: I haven’t tried hard and wanted to learn CDXML concepts anyway). We move back to PowerShell than…