Windows PowerShell
An Interview with Lee Holmes
Lee Holmes is a developer on the Windows PowerShell team and author of the new book Windows PowerShell Cookbook (which includes a foreword written by Scripting Guy Dean Tsaltas). And if that isn’t enough, Lee also writes the Precision Computing blog. In this Script Center interview, Lee talks about his book and about Windows PowerShell in general.
An Interview with Lee Holmes
To start things off, can you tell us a little bit about yourself and what it is you do?
I’m a developer on the PowerShell team, and I own all the security stuff: remote-signed, restricted – that’s all mine. I also own the provider infrastructure – registry, certificates, drives, all that. One of my responsibilities is the code that allows someone to write a new PowerShell provider. Are you writing a new provider for Windows PowerShell? All the pain you’re about to go through is my fault.
How long have you been on the PowerShell team?
I’ve been on the PowerShell team for about three-and-half years now, but I actually started using PowerShell way back in its early betas, back when it was still known as Monad. When I first started playing around with PowerShell, I was working for Encarta, doing online security stuff. One day I was poking around Slashdot and I heard about PowerShell from Slashdot. I heard talk about this cool new shell/scripting language that Microsoft was developing. I thought to myself, “Hey, I work at Microsoft; I should look into this.” I sent an email to the C# mailing list and someone pointed me to the PowerShell team; from there I got a copy of the software and started messing around with it. Like I said, these were very early betas; for example, when I asked someone how to clear the screen they told me, “Just hit ENTER a whole bunch of times until your screen is cleared.” Despite that, I almost immediately started using PowerShell as a development tool; in fact, I got our operations guys at Encarta very excited about PowerShell. From there I began to get more involved in the PowerShell discussion list, and eventually got a chance to talk to Jeffrey Snover and then join the team.
Obviously PowerShell piqued your interest. What was it about the program that you found so intriguing?
I was a Unix guy for a long time: I ran a Web site using the FreeBSD software, and while I was at university I used Linux as my desktop machine. I did all the geeky stuff: I set up BIND and SendMail and all that stuff. Pretty sad, huh? Because of that background, however, I knew that shell scripts – as useful as they can be – tend to fall apart after about three commands. The problem is that you lose information as you pipe from one command-line tool to another. Traditional shell scripts – which rely on text processing – are very lossy. For example, you start off with three columns of information; you then lose one column when you run this command, then lose another column when you run a second command. In Unix you usually get about 4 commands, maximum, in a pipeline; you can’t have 5 or 6 commands because by that time there’s not enough information left to do anything. That’s the problem with text processing. But PowerShell doesn’t rely on text; it uses objects, instead. And that’s what really attracted me to PowerShell: with PowerShell you can string together as many commands as you want, because – with objects – you never have to lose any information. You can keep sending things through the pipeline as many times as you want.
Another thing I really like about PowerShell is that it greatly expands the options available to you: you can work with COM, you can work with WMI, you can work with the entire .NET Framework. One tool opens up all these enablers, and in a consistent, predictable fashion. Sure, you can work with many of these enablers without using PowerShell, but you have to learn how to use Regedit and you have to learn how to use ADSI Edit, and you have to learn how to use Wbemtest, etc. With PowerShell you learn one syntax and one approach, and then you can work with all these different enablers.
How did the book come about?
O’Reilly originally approached Jeffrey and asked him if anyone on the team would be interested in writing a book about PowerShell “hacks,” and Jeffrey gave them my name. We started talking, and then decided that maybe a book about hacks wasn’t the best way to go. After all, hacks appeal to a very limited audience, and are really only useful when a bunch of people have already mastered the basics of a language and are ready to move on to something a little more sophisticated. We decided that we needed to get people interested in PowerShell in the first place, and a good way to do that was to show them how to perform a bunch of useful tasks. That’s where the idea of the cookbook came in.
So what is a cookbook?
The idea of a cookbook is that we just tell people how to do things. People don’t necessarily want to know all the ins and outs of a language; instead, they just want to back up an event log. Well, we have a recipe for that.
Wasn’t it hard to work full-time as a developer and write a book as well?
It really didn’t take me all that long to write the book, but it took me a long time to research it: I was always in the newsgroups and the mailing lists, trying to get an idea of what people wanted to do. That’s really what the book is: it’s just a collection of “recipes” that show people how to perform useful tasks. I spent an enormous amount of time analyzing the tasks that people do the most, as well as the tasks that they want to do but haven’t been able to do. I like to think that every page in the book has something fundamental and unique. Too often in the computer world you have these “author farms” where writers just regurgitate whatever happens to be in the help files. I didn’t want to do that; with the exception of some of the security stuff the information you’ll see in the book is not in the help files.
When the Scripting Guys were in Barcelona we watched one of Jeffrey Snover’s presentations, and he made the point, “There are already a lot of good books about PowerShell available.” He then showed a slide featuring a huge stack of PowerShell books. If there are already a lot of good PowerShell books out, well, why would anyone be interested in yours? What makes this book different from some of the other books already out on the market?
I think the appendices are a good example of what makes this book different from similar books. Often-times in a computer book there will be a chapter on, say, regular expressions, and rather than explain things the writer will just say, “For more information, go to MSDN and search for regular expressions and .NET.” I tried to do something a little different; for example, I went through the regular expressions syntax and showed you everything you can do with regular expressions, along with a little code snippet that shows you how you can do it. I went through every COM object that installs with Windows, grabbed the ProgID, and made sure those objects work with PowerShell. I looked at every WMI class; the list goes on. I like to think there’s great value just in the amount of research that was done in order to put together the appendices. The appendix isn’t just a way to make the book look bigger; there’s some good stuff in here.
Who is this book aimed at?
I like to think that the book has a little something for everyone. You don’t need a lot of PowerShell experience to use most of the recipes; if you know how to copy and paste you’re in business. However, I also tried to include a few things that would be of interest to those early adopters who’ve been playing with PowerShell from day 1. That’s why I show people how to do things like invoke a PowerShell process on a remote computer, or access the Windows APIs.
Let’s talk about PowerShell itself for a moment. Let’s say I’m a system administrator; as such, I tend to be a little skeptical about new technologies. Besides, every day someone comes out with some new product that’s supposed to change my life forever. What makes PowerShell different from all these other technologies?
I really believe that PowerShell is the one language that is tailor-made for system administration. What are the things people find really hard? Well, to name two, recursion and file streams. Those are difficult to do in C++ or C#, but PowerShell is designed to take care of those difficult problems for you. In all seriousness, 3 pages of C# code can often be reduced to a single line of PowerShell code. How do you get a list of all the processes running on a computer? In C#, you have to start by loading the System.Diagnostics.Process class and then figuring out the properties you need to reference. In PowerShell you just type Get-Process.
Oh, and here’s a hidden gem that people don’t always realize: in PowerShell a script command is exactly the same thing as a command-line command; there’s no difference. You don’t have to make a jump from command-line administration to programming; that’s because the commands, and the syntax, are identical. A lot of people have asked us, “Why didn’t you use C# as the scripting language for PowerShell?” Well, that’s because we didn’t want a scripting language for PowerShell. PowerShell is PowerShell whether you’re typing commands at the command prompt or typing commands into Notepad to save as a script. We wanted to treat PowerShell as a shell first.
What’s the biggest challenge you’ve faced in getting people to take PowerShell out for a test drive?
One problem we face is that the first PowerShell scripts most people see are likely to have been written by the super-passionate guys, the guys who just want to play with the technology and aren’t concerned with teaching that technology to people. These are the people who like to use shortcuts that kind of mark them as an “insider;” that’s why they use the % sign instead of ForEach-Object, and why they use ? instead of Where-Object. The emphasis in many of these scripts is on carrying out some task (and not always a useful sys admin task) using as few keystrokes as possible. There’s a lot of this: “Hey, look what I can do with just a single pipeline.”
Newcomers get a little nervous when they see that stuff. Well, I want to emphasize that this is not the way that it has to be. For example, in the book I use full command names in order to try to make the sample code more readable and more approachable. I know that some people will look at my examples and say, “Wow, look how wasteful PowerShell is!” Well, maybe. But I’m writing for the sake of teaching, not for the sake of execution. If you’re typing commands at the command-line, well, hey, be as pithy as you want to be. In a case like that, I fully agree that the less typing you have to do the better.
But scripts are different?
Yes, scripts are different. Remember, with scripts you’re a reader as well as a writer: a year from now you’ll be reading that script and you need to be able to understand what you did, and why you did it. Early adopters tend to like technology for the sake of technology. You see that a lot with Perl; it’s all “Perl golf,” trying to do things with the fewest possible keystrokes. There’s nothing wrong with that, except that early adopters are somewhat overrepresented on the Web. People think that’s the way that you have to do Perl or PowerShell, and that’s simply not the case.
That’s why this book is aimed at people who maybe haven’t given PowerShell that much thought, who’ve seen some of these early adopter scripts and thought, “Well, I’m not going to be interested until PowerShell helps me solve my day-to-day administration problems.” I’m trying to show them that PowerShell already does help them solve their day-to-day administration problems.
And you don’t think that people are aware of that?
It’s interesting to compare the questions that come up most often in the Windows scripting and PowerShell newsgroups. In the PowerShell newsgroups you get a lot of language issues; in Windows scripting the focus is more on, “How do I do this particular job?” That’s what I’m trying to do: help people do a particular job. I just happen to show them how to do this using PowerShell, but that’s not really what the book is about; the book is really about getting things done.
So is this book the first and the last, or do you have plans to do another one?
I’ll probably revise this book for version 2 of PowerShell, but only time will tell whether or not I do another book. Truthfully, between my book and Bruce’s book I’m not sure what else there is to tell.
Any last words to the system administrators of the world?
My advice to people is this: don’t be afraid to try something new. So many examples are targeted towards early adopters that people see PowerShell and think, “This is not for me.” That’s not true: PowerShell is for you. Remember, at heart PowerShell is simply a shell that makes it easy for admins to type in a few simple commands and get their job done. It’s just a bonus that PowerShell also does a bunch of other things really well.
