Windows PowerShell in Action

jlcopeland writes "For two decades I've hated the command prompt in DOS and Windows. Inconsistencies abound and everything is a special case. The fallback on a Microsoft box has been running a Unix shell under Cygwin or installing Microsoft's own Services for Unix (or its predecessor, Softway's Interix), or by scripting in Perl, but those only get you so far. Having co-written nine years worth of trade rag columns using mostly Perl as the implementation language for the samples, and thinking of every problem that comes across my desk as an excuse to write a little bit of scripting code, I've got some well-formed views about scripting languages and what works and what doesn't. That means I've been eagerly watching the development of PowerShell since it was called Monad. It's got the advantage of being a unified command-line interface and scripting language for Windows, even if it does have a dorky name." Read the rest of Jeffrey's review. Windows PowerShell in Action author Bruce Payette pages 576 publisher Manning rating 9 reviewer Jeffrey Copeland ISBN 1932394907 summary Guide to PowerShell, the new Windows scripting language

Bruce Payette's Windows PowerShell in Action is a great overview of PowerShell, aimed at an audience that's got some experience with other scripting languages. Bruce's book is a big improvement over Andy Oakley's earlier book, Monad, which I had been using: it's more complete and it's up-to-date for the first release of PowerShell. It's got great (and sometimes amusing) examples, and feels like the Perl Camel book in flow. When I was reading it in the gym or someplace else away from the keyboard, I kept wanting to run back to the office to try something out. There are also useful "why it works this way" digressions, which provide a lot of context. Since Bruce was on the original development team, wrote most of the commandlets, and was responsible for much of the language design, those digressions are more authoratitive than the directors' commentary tracks on most DVDs.

In outline, the nine chapters in the first part of the book build up as you'd expect: overview and concepts, to data types, to operators, to regular expressions, to syntax, to functions, to interpreting errors. It covers that ground better than many language books that now litter my shelves. The explanations are clear, and the examples are almost all exactly on point. It took me a second reading to realize that my complaints about the regular expression sub-chapter wasn't about the chapter itself, but about some of the implementation decisions; that's an argument about style more than substance, and an observation about me, not about Bruce's writing or PowerShell. The first part of the book is the "mandatory reading," if you will, to get the language down and begin exploring on your own.

The second part is where the real applications are covered. That's the part that you especially want to read sitting next to the keyboard. As you'd expect, the example code is available from the publisher's web site to start you off — look for "Example Code" under "Resources." There's a very good discussion of text processing and how-to-handle XML, complete with some not-obvious warnings about traps to avoid. I've been working very carefully through the really good chapter on using GUIs with PowerShell, "Getting Fancy — .NET and WinForms," and my own proof of concept for that has been rebuilding an old C++ data entry application into a much simpler PowerShell script. As a nice side effect, Bruce's book (and the WinForms chapter in particular) provide a gentle overview to some concepts in the .NET framework, which I hadn't had an opportunity to delve into. The appendix on using PowerShell as a management application will be especially useful to system managers; that was one of the original PoweShell target audiences, and the language achieved that goal very well. The appendix on the language's grammar is really useful, and I keep flipping back to it to check on things.

After Oakley's Monad appeared, there was a long gap before the next PowerShell book appeared. Bruce's book looks to be the first of the post-release wave. If all it had going for it was the authoratative pedigree of the writer, it might be worth it, but it's also well-written, well-organized, and thorough, which I think makes it invaluable as both a learning tool and a reference.

You can purchase Windows PowerShell in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Don't knock it until you try it

[PhrostyMcByte]

Powershell is very powerful. Much more so than cmd.exe. I don't have significant enough experience with bash to compare the two but I would not be surprised to learn Powershell equals if not beats bash at the shell game. I wouldn't say it is ready to replace any of the scripting languages just yet.

I have been using it for a while now and the single (semi-major) problem I can find is memory usage. It is a hog at best, and at worst when you are using it semi-heavily it can easily chew up 1GB of memory. That's even with giving the GC something to work with, ie unsetting $vars when you are done with their data.

Monads are windowless, get it?

[Brunellus]

I wish they'd kept "monad" as the name. It was a deft tip of the hat to Leibniz's Monadologie, which held that monads were the windowless metaphysical atoms of perception itself.

Great Review

[water-and-sewer]

I don't use Monad (:s/M/G/g) or intend to, so I don't care much about the book. But what a great review. We get a lot of amateur reviews around here, but this one was particularly well written, clear, and informative. Nice job, homie.

I'd love Powershell, if it weren't for one thing:

[3m_w018]

It's slower than cold molasses up a hill.

It takes a few seconds for the prompt to appear, and if I run a "dir" operation with both cmd.exe and PS in a directory with hundreds of files, cmd.exe will beat it in seconds.

I'm not running a slow machine(core duo 2, 1GB of RAM). Is there something that needs to be configured to make it suck less?

Re:At this rate...

[archen]

There's actually a lot of other cool things about it as well. I've been using Jscript to do stuff since Win2k (screw that VBscript garbage) but there are obvious limitations at the scripting level, but in the end you're always stuck in cmd.exe

I was skeptical when I first heard about Monad. I mean it seemed obvious to me that Microsoft just didn't get the point of a "shell" which is supposed to be simple. With a pending install of Exchange 2007, the power shell is required so I figured I'd start to dig into it. I have to say I'm rather impressed.

First of all, it is actually simple. Not only that, but the syntax is EXTREMELY CONSISTENT. And honestly I cannot stress that enough, because if you think you know part of a command you can usually figure out the verb/noun syntax to use. It also allows shortcut versions of commands so you don't have to type the entire "wordy" version of the command. Aliases are supported too. Another cool feature? You can navigate the registry like the rest of the file heirarchy.

I'm a big fan of bash, but I must admit that at times it gets old shuffling stuff with awk and cut and so forth. By getting objects you can take what you want out of it, and not worry about the biggest Unix terror - the text output changing. If whatever you're trying to do doesn't support .net objects, you can still pipe text.

Overall it's pretty awesome technology and I must give MS credit where it's due. Not that I'll be switching any of my FreeBSD servers to Windows because of it, but it makes windows administration orders of magnitude better. Too bad it got dumped in Vista. I've heard it will be included in service pack 1 though.

Re:Windows "power shell"?

[MS-06FZ]

has microsoft submitted to linux and unix? we have had a "power shell" for a few decades now.. You sure about that? I think we have crusty old 1970s shells with a veneer of tab-completion and command history added for convenience. I would really like to see that situation change. I like the CLI and I think it's a powerful way to work - if the shell is up to the task. CLI shells ought to be able to, for instance, access the GUI (if any), as well as interact with running applications. These tasks can technically be done with just about any shell - but only in the sense that a program that runs under the shell can do some task and report back information to the shell environment - and the ability to do that is limited by what data types the shell can handle. Bash can handle one datatype, basically - text. It can't handle structured data, it doesn't really support binary data or numbers, let alone live objects you could interact with. I think this is a source of a lot of busywork in traditional shells - you run a program that, say, prints out numeric data from a matrix file, then to process that data the next program in the chain needs to parse the overall output, convert the numbers back to binary, and then probably re-format and print them out as text again. It makes no sense.

I really, really want the Linux CLI to be modernized. (Lots of time is spent working on the Linux GUI, but it seems like when it comes to the CLI people are content to let it rot.) I've spent a lot of time trying to figure out how I would go about doing that. I've read a bit about PowerShell - it seems interesting, at least, and promising. For instance:
- It can wrangle live .NET objects and complex datatypes
- It encourages a unified interface (conventions for command options, etc.) for CLI programs and utilities
- It applies these new techniques in conjunction with existing, traditional shell mechanisms, like pipes.
- It endeavors to make documentation and general information about commands easier to access

Now, there's also things I don't like so much - for instance, the distinction between "commandlets" and normal commands. (To be fair, this is largely due to the fact that most existing code in the world is written either for a traditional CLI or a GUI - so most code isn't going to know how to deal with a smart CLI anyway. But I think there are better solutions.)

I think it's kind of a drag that Microsoft may now have a better CLI than Linux - but I think that's a situation that can be changed.

Re:Windows "power shell"?

[MS-06FZ]

Text is universal, though, and it lets you have a single means of output for simpler programs. Want to read the results immediately? Just call the program. Want to save the results? Dump them to a file to review later. Text is only universal because we've made it universal. This is the same idea behind XML - it's mainly useful because it's recognized. And text isn't "human-readable" - it's binary just like everything else. It just happens that the process of displaying it is rather simple and the programs to do that are already out there.

If you look at Powershell, they've got the "read immediately" process down - commands like "Format-Table" come to mind. Yeah, big deal, right? It's what PERL was born to do. But nevertheless - if you run a command and it generates an object, a meaningful printed representation of that data appears on the console. If you want it to look nicer, there are commands to format the output. I think the shell would be better if the user didn't need to handle that step explicitly - I have some ideas for how that could be done. (I am very interested in writing a Linux shell with these kinds of capabilities.)

This makes it trivially easy for programmers to modify the output, or for the users to use it in unexpected ways. It means we don't need a separate program to convert binary data to a human-readable form first. From my perspective you've got it backwards. Every single program in a pipeline chain is burdened with the job of converting "human-readable" data to a useful, processable form - and then back to text again for the next chump in the line. So maybe you save one step, because you don't need to reformat the output of your last command - but you've added on two steps for every command in the chain (minus one, for the first) - and when programs start to get even moderately outside the realm of the common, everyday stuff, the user starts having to deal with those processes themselves.

Complex datatypes in a shell are only good if you're using a set of languages that can deal with the same objects. With Unix, not all your languages have a concept such as an object -- not even a struct. Even then, you need a human-readable form for them, even if they're converted at the user's request.

As long as Monad has that, it's probably decent. But that's going to be application-specific. True, that is a problem. Not so much the languages' limitations in handling objects - that's just syntax. You can write object-oriented code in C if you feel like it, and certainly C can interface with object managers like CORBA - it just wouldn't be especially fun. It's more the problem of having a common communication format - that's a hard sell because people don't think they need it, and it's a bit of a tall order to mandate something like that.

In what sense is Monad's pipeline communication format "application-specific"? It can deal with any .NET object. If you had an object with a field called "Title" that had a value "Foozle", you could access that any way you like. It's not application-specific. You want a human-readable form? "Title : Foozle" pretty much does it. :)