When I started my first real job in IT (almost 15 years ago) it felt a bit odd. At that time I was spending most of my time on Linux, yet my work required mainly Windows skills. My work colleague knew my background so I got task that supposed to be “gateway drug” to get me back on Windows side: updating backup script that was written in batch. Pure batch: I was not allowed to install any of the *nix tool’s ports to aid me in this project. And there were few significant requirements, and new one arrived every now and than.
Initial plan was different, but it looks like next Tuesday (well, more like Wednesday in my time zone…) I’m going to present about OMI for the third time. This time I will present for Omaha PowerShell User Group. You can find meeting details (and sign up) here. I must say I’m super-excited. This group is relatively “fresh” (this will be their 2nd meeting). It’s lead by Jacob Benson and Boe Prox. And Boe is a person that I “know” for years. We never met in person, but he was one of few people I virtually known in my early PowerShell community days. That plus the fact that I learned a ton from his blog. No surprises, blog title says it all, right?
When you hold a hammer you may end up seeing nails everywhere. I won’t pretend that I don’t have this problem. PowerShell is my hammer and “I see nails”. For example: when I have to work with a product that doesn’t allow me to perform some system-wide searches but allows me to export entire configuration to XML document I will improve my XPath skills and use my hammer for this nail. My XPath series is side effect of that.
I have more ‘nails’ around me though. Like ticketing system (lets keep it nameless) that has (for my needs) very poor search mechanism, but has SQL backend. I could probably use API that this product has (I think? Frankly, I didn’t even try to find it…) but writing something SQL-aware seemed more natural and reusable. After all – I may use the same ‘skeleton’ for anything else that has SQL backend.
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.