Windows PowerShell in Action 442
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.
At this rate... (Score:5, Insightful)
Re:It's amazing people still use windows. (Score:2, Insightful)
YOu do realize that 90% of users have aboslutely no need for a shell, right? I would argue most power users don't need a shell.
Re:It's amazing people still use windows. (Score:2, Insightful)
Re:It's amazing people still use windows. (Score:2, Insightful)
People use Windows because most people are not looking for the same things in an OS that you are. I know it's an easy way to get some karma here on Slashdot, but saying you can't believe anyone uses Windows because the shell sucks and you've had bad experiences resizing pictures is absurd.
Re:At this rate... (Score:2, Insightful)
What's to understand here?
Re:It's amazing people still use windows. (Score:5, Insightful)
I'd say that power users who think they don't need a shell don't know what they're missing ; they could have a lot more power.
The gentleman sitting next to me has recently discovered and raves about WinGrep, a GUI file search/replace utility with RegExp support. It's not bad, but it can't compare with a shell - you can't, for instance, search for a bunch of files containing your desired pattern match and invoke an external utility to process each one. And anything that the original application designer didn't visualise as a feature is excluded. He's easily capable of comprehending grep and sed, which would do the same job for free, but he's more comfortable with the GUI.
In a *nix style shell, the ability to pipeline STDOUT through a whole bunch of little utils is the tool of a real power user - and it has a nice easy learning curve, you can pick up new commands as and when you like, and combine them with old favourites. The downside to the *nix shell is that very often you have to perform some esoteric text processing to get what you want, which means learning tools like awk and sed. Powershell works by passing objects through the pipeline - objects that have useful properties. It's even an improvement with old-style executables that emit pure text - the
The GUI equivalent of a shell for a power user would be a pipeline composer where you can take various widgets representing actions and plug them together. Perhaps something like the DTS transform designer in SQL Enterprise Manager. Or maybe not
Re:Monads are windowless, get it? (Score:2, Insightful)
Re:It's amazing people still use windows. (Score:3, Insightful)
Sure you can live without a vacuum cleaner, but your carpet and overall cleanliness is going to suffer for it. I know people who live in apartments without vacuum cleaners and they are very similar to computers who's users don't use or understand shells.
perl -e (Score:2, Insightful)
If we want/need to call an OO scripting language, we can do just that thank you very much. Typical Microsoft non-solution to a non-problem just so they can lock users to their ailing platform.
Re:Don't knock it until you try it (Score:2, Insightful)
As far as Powershell, why worry too much about what people who haven't used it think?
Re:Don't knock it until you try it (Score:2, Insightful)
One would certainly hope so, considering how old and antiquated MS-DOS and cmd are. I mean, come on. How could it NOT be? I looked at the user guide for powershell, and saw that "Windows PowerShell is based on the
There's a strike against it right away.
I've been programming command languages for four decades now, and of course there will be unique features to the command language for any operating system. For example, the DCL on the VAX and the CCL on NOS naturally won't interchange on the computers. But times have changed- With the ability to run perl and other open tools on any system, why make something as obtuse as Powershell?
Let's look at an example command "Get-PSDrive -PSProvider FileSystem." Even with command completion, this looks cumbersome as hell. Kinda reminds me of COBOL. Computers and their programs are supposed to do the work, while reducing the work for the users.
Read the manual, THEN knock it.
Re:The philosophy behind textual data (Score:3, Insightful)
Sort by name:
du -x / | sort --method 'toString'
Sort by size:
du -x / | sort --method 'getSize'
Also you could do things like make your own output formats without having to use
Look I'm sure Microsoft screwed it up so it's stupid since they basically screw up everything they do. But the actual idea behind it doesn't have to be as bad as your rant. Especially since you can always convert any object to a string and then are you back to unix.
Re:I'd love Powershell, if it weren't for one thin (Score:3, Insightful)
Re:The philosophy behind textual data (Score:5, Insightful)
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.
.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...)
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 -
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
Re:At this rate... (Score:3, Insightful)
Sure, the pipe can pass anything, but as there is no standard to pass anything but ASCII encoded text, you're more or less restricted to use this on Unix otherwise you'll have to modify all the tools: watch how slow the transition to Unicode was..
In theory, one could define a 'common' binary encoding of objects easily on Linux, but then you have to modify each tool, each scripting language to make it work, a huge task..
In practice, especially on Linux it's nearly impossible: there is no central authority: remember, there are *still* copy/paste problems between some toolkits..
PowerShell isn't a Shell It's a scripting language (Score:2, Insightful)
For example you have python. Python has several shells you can work with. The default python shell or ipython shell are two examples. Perl has been around forever. Ruby. Haskell. PHP. Lisp.
Whatever floats your boat.
Object oriented, procceedural, functional languages. Whatever you want.
A Unix shell like Bash or pdksh is designed as a _user_interface_. Your ment to work in it for day to day tasks. You don't need to be a programmer to work it and scripting is simple and effective.
And why text? Because text is universal. Everybody understands text. It's human readable, it's human editable. You can have all sorts of programs that are completely different, but they all understand text. Text is easy, text is how the world is ran.
So Microsoft actually fubbed this one pretty badly. They aimed for a shell and hit on scripting language. Microsoft Windows already has a bunch of scripting languages. PowerShell is just another one.
Sure I can run around my file system with ipython and write my own replacements of common unix commands and all sorts of crap like that, but it will take a crapload of work to turn it into something that it's not.
The reason in Linux you use Bash for scripting is because it's convient. You always need a user interface aviable, and everybody uses it. So it's always going to be around. So you use it for things like init scripts or little things to setup the environment to launch larger programs and lots of other utility items.
Remember:
Text is convient, universal, and easy to understand and use (due to human readable nature). Text parsing isn't difficult if you have the proper tools.
The Unix shell is ment to be used on a daily basis. It's easy to use and convient. You don't need to be a programmer to script with it.. it takes a single sunday evening to get most of the basics down for a reasonably intellegent person.
It's used for scripting were you have simple, smaller tasks. Or you have tasks were other programming languages are not aviable or may not be present... like init scripts.
Powershell is neither easy nor convient. Nor it is easy to use for a non-programmer and it's not designed to be a user interface. It's a scripting language. One of many.
Re:The philosophy behind textual data (Score:2, Insightful)
As opposed to writing a nasty and error-prone script to attempt to transform the object into something you can use in Powershell, I suppose? One of the big advantages of text interfaces is that you can test it on the keyboard and screen. I can quickly and easily create test cases in my text editor, to create a test case for a binary object you must write another script, and risk making a mistake.
An example of a common error is date formats. When I write a date in my text editor I know how I do it, "May 2, 2007", or "2/5/2007", or "2007/05/02", etc. When you have a binary object you have no way of knowing for sure the exact internal format you have used for the data. What if the person who sent you a binary file used two digits for the year and forgot to tell you? Binary data is much more error-prone than text.
And because it's objects I can further process this any way I want beyond what I'm just displaying on the screen, and I can save it to a fully type-safe variable to continue to process further in script, or serialize it out to XML and do side-by-side comparisons.
Just as you can further process text data in any way you want. You can save it to disk, you can compare it side by side, you can even *gasp* convert it to XML if you want. Anything you can do with binary data you can do with text, but the opposite is not necessarily true. You cannot edit a binary object with a common text editor like the one you use to edit your scripts.
I repeat what I said in my former post, Microsoft has no idea of what they are doing. The type of work you mention is an *application*, not a shell command. Bash is for controlling the computer itself in a simple but powerful way. It's not meant for the applications that run in the computer. The difference is the 1GB of memory that Powershell uses compared to 1MB useb by bash. The one-liner I mentioned is for situations like "disk full? I thought we had plenty of space, let's see
When you want to create applications or more complex scripts there are plenty of options available. There's Python that's much easier to learn than Powershell, there's Perl that has plenty of ready-made scripts available, there's Ruby that already does all that "object oriented" stuff if you are into that, there's C for creating highly optimized code, there's Java when you need to coordinate a big team of programmers. Powershell is doomed to failure because it wants to become each of those languages, without being as good as any of them in their respective specialties.
Re:At this rate... (Score:3, Insightful)
Re:Come one, sell me this shit. (Score:5, Insightful)
Now imagine the same thing, but instead of passing in strings you could pass in/out native data types, full objects, other methods, etc. That's PowerShell.
Re:PowerShell isn't a Shell It's a scripting langu (Score:5, Insightful)
The idea benind the Unix toolset and shell is that everything is reduced to a common lingo -- a character stream. Each tool can then be "used as designed", or "misused". The classic example is the original Unix spell implementation. The tool designer promises to accept as wide an input range as possible, to output consistent streams, and not be verbose.
The actual use (misuse) to the tool is left to the shell and user.
The Object philosophy means that input to a tool MUST have certain methods available. If the correct methods are not implemented over the object, an adaptor tool must be used. Microsoft ensures that all PowerShell tools work together IN NORMAL USE. Obvious "misuse" is not (necessarily) supported.
This makes common usage cases easy, but makes "outrageous" cases almost impossible (unless you reach for VC++ and write your own adaptors).
As an example -- I do a lot of "performance analysis", which entails examination of log files, conversion to normalized scales, and running the results through GNU Plot to get images to paste into reports. There is almost always a need for custom shell scripting to do the log examination and reduction.
Now, this IS possible in PowerShell, but only by treating it as a "Unix (gasp, how horrible!)" type shell.
Since the exploration phase (and creative "misuse") is my primary area, PowerShell doesn't have much to offer me. But, for a developer living in the straight and narrow land of "how it should work", it is probably the next best thing to sliced bread.
As to the "PowerShell" equivalent of the non-Microsoft world: I find that I still (occasionally) cook up SNOBOL scripts. When writing compilers for an old course, it was the ONLY programming language specifically not allowed for assignments (it made lexing, parsing and generation much too simple).
Re: Windows "power shell"? (Score:5, Insightful)
There is, however, no universally agreed syntax for "objects". Sure, there have been attempts, but I doubt any of them will succeed, maybe ever. Different systems have so vastly different opinions of what an object is, and I believe that is how it should be, because if all systems would have to have the same idea of an object, you would be locking them into a predefined design pattern, and innovation might decrease. I don't know if maybe people said the same thing about bytes in the 50s and 60s, so I wouldn't bet my prediction will turn out to be correct, though.
Of course, this is perfect for Microsoft. They don't want other systems, anyway. As long as anyone can agree on the .NET definition of an "object", Microsoft will be happy. However, even then, the fact remains that not every .NET object is serializable -- you can't just take an arbitrary object and squirt (pun intended) it over the network or store it on disk. As long as you wish to communicate with anything outside your own VM, text (or at least a byte stream) is necessary.
Heh, that's one of the weirder statements I've seen as of late. Kind of like saying that you can't "speak" in a telephone, it's just a PCM stream anyway. Call me weird, but I'd argue that text is human readable by definition. I do (kind of) see your point, though, but I don't agree. Text is always human readable, because it has such an internal structure that makes it human readable with an extremely simple and universally standardized (except for charset) algorithm. If you just have an "object", though, there's no universal algorithm for turning it into a visual structure. Usually, each object class even has its own such algorithm, which isn't usually reversible (unlike text), and not every class even does. To begin with, there is, as I wrote above, no guarantee of any sort that an object is even slightly serializable.Not that I think that you're wrong in every possible way. I definitely think that an object-oriented shell may have its virtues, but it's never going to work outside its own VM. Text is universal, since you can send it anywhere and receive it from anywhere. That "anywhere" includes a human, too.