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

Monad

[Profane MuthaFucka]

Named after the designer lost a testicle in a tragic chair throwing accident.

Re:Monad

[jsnover]

That is not the case. I gave it the name Monad because of my respect for Leibniz. Wikipedia has this right: http://en.wikipedia.org/wiki/Windows_PowerShell

At this rate...

[pnuema]

...in 20 years MS will invent UNIX.

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.

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.

Well, *that's* unique

[Angst Badger]

Inconsistencies abound and everything is a special case.

You should switch to bash and the GNU tools.

Oh, wait.

Re:Don't knock it until you try it

[TBone]

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.

Unless MS rewrites all of their other commands to accept STDIN/OUT, Monad will never surpass the shells. The power of the shells isnt' their programming flexibility, it's their ability to incorporate all the other UNIX tools and commands via pipes to do what you want.

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.

Another reason it will never surpass the shells. They're lightweight, and flexible, and I don't need a Garbage Collector running in the back end to clean up my object allocation.

Everyone should follow their lead...

[Anonymous Coward]

Now all we need is for Sun to develop a Solaris-only shell, Apple to develop a Mac-only shell, and RedHat to develop a Linux-only shell. I hate re-using code because it forces me to solve new problems every day. I'd rather create new value on Mondays only, and then spend the rest of the week re-doing the same work on my other platforms. It gives my mind a chance to rest, and I can drink heavily mid-week and still be able to do my job.

I sure hope they charge extra for it, make it a resource hog, lock out third-pary extensions, and then discontinue it as soon as I'm dependant on it. I really liked the 1980s and look forward to reliving them.

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:The philosophy behind textual data

[MS-06FZ]

it treats piped arguments as objects instead of strings, Psh lets programs access the data directly, instead of having to manipulate large amounts of textual data with tools such as grep or PERL.

Then they have absolutely no idea about what they are doing. The one big advantage in using pipes is that any application can handle text data.

Let me give one example: I use the sort command all the time, it sorts data by lines of text, lines are compared according to criteria passed in command options.

Now, imagine if it depended on binary objects. For every sort operation one would have to write a comparison function to decide which object should come before the other. Writing a special function would mean declaring some form of callback, or maybe some people would call it a closure, whatever. And so on.

Here's one simple command I use when a disk starts getting full to see which directory is the data hog:
du -x / | sort -nr > mem.txt &
What this command does is check the disk usage (du command) in the root directory (/) without looking at symbolic links to other disks (-x option). The result is piped to the sort function, where it's sorted by the numeric value of the first column in reverse order (-nr option). The sorted result is sent to a file named mem.txt. Since checking the whole disk may take some time, it's done in the background (& command). After it finishes, I have a file with the size of each directory in the disk, one line per directory, ordered by size, larger directories first.

See how powerful it is, having data represented as text? Try writing this line as a Powershell script.

Another advantage of having data in text format is that you can test it using the keyboard and screen very easily, no need to run a special debugger.

Instead of trying to reinvent Unix poorly, Microsoft would do a favor to its customers if they accepted Unix is a mighty fine OS and adopted without shame its best features.

I strongly disagree with most of what you've said. Here's why.

The supposed "ease" of dealing with text is an illusion - it's a fallacy that's built out of
1: the fact that textual formats are usually organized such that we humans can read them if we send the data out to a console
2: the fact that Unix types have built up a formidable array of text-wrangling utilities to deal with these problems
3: a general assumption that the reading and writing of formats passed between processes won't pose any real challenge to process.

The relative "ease" of text is negated if three corresponding conditions are met in a shell dealing in structured data:
1: Data is structured (or information about the structure of the data is communicated) using mechanisms that are respected by all tools involved. (In other words, there's some kind of Lengua Franca for the structured data - .NET provides this, of course. Similar technologies could provide the same thing on Linux. It's a tall order, mainly because of all the programs in the world that are written for naive assumptions about the shell environment...)
2: The structured data that is used in inter-process pipelines is given suitable (preferably interactive) display methods
3: An appropriate set of data handling tools are introduced, generic enough to work for most problems and powerful enough to be effective.

The problem with textual formats for structured data is that there will always appear ways that you can do it wrong. For instance, what if a field contains the character (or set of characters) you're expecting to use to delimit the fields? Well, that's why find has a -print0 option, isn't it? Now, what if the field could contain null bytes, too? Then maybe you use escape characters - and the process of reading in the output from the previous command starts to become a more complicated parsing problem.

You cite how easy it is to sort based on a field (and, to extend the exam