Slashdot Mirror
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.
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.
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.
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.
This space for rent. Call 1-800-STEAK4U
For those that didn't get it, his comment was a play on the famous:
"Those who do not understand Unix are condemned to reinvent it, poorly"
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
You mean again?
"It ain't a war against drugs.it's a war against personal freedom" --Bill Hicks
Wake me up when *nix gets an object-oriented (rather than text-oriented) shell. Because that is what makes Powershell so unique. Yes, it has plenty of builtin functions to make tasks easier, but the real advantage is that everything you pass between commands is an object.
You don't have to worry about interpreting text output - you just access whatever data you want directly. Many of the commands are easily chainable into something like "ls | select fullname,length | sort name | format-list | out-printer".
HAHAHAHAHAHAHA. Thanks! I needed a laugh today, and saying that a shell can use up to a gig of memory provided that laugh.
Let's see on my Mac with OS X, my bash shells, which admittedly aren't being used semi-heavily, are using:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND
nobody 879 0.7 -0.0 27816 856 p3 Ss 11:06AM 0:00.12 bash
nobody 281 0.0 -0.1 27816 1472 p1 S+ 11:09PM 0:00.17 -bash
nobody 348 0.0 -0.0 27816 904 p2 S+ 11:37PM 0:00.16 -bash
Hmmm... that comes to an average of 1078kb of memory per shell. And PowerShell can use up to a GIGABYTE?
I'm still laughing.
You forgot MKS toolkit which has most if not all of the standard UNIX utilities along with vi, bash, ksh, sh, awk, sed, etc. What more could you want?
http://www.theregister.co.uk/2005/09/05/chair_chuc king/
;)
There is all you need.
What I'm saying is that for power users, Windows sucks because it doesn't provide any features geared towards them. I'm also saying that for non-power users it sucks, because you can't just put an image on your desktop, and have it resize to fit the screen automatically. You have to open it up in an image editor, resize it to your desktop, then put it on your desktop. I don't see what any particular person likes about windows, power user or not.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
It really fails in two places. Firstly, it's slow. You wouldn't have thought it possible for a command shell to be that slow, but it is. It's so slow it was actually quicker for me to use explorer. It is god-awfully, mind-bogglingly slow.
The second problem is that it had no easy way of being accessed over a network link, last time I looked at it. So there's no chance of SSHing into a Windows box and administrating it from there, at least not without fiddling with a lot of hacks and workarounds I couldn't get to work.
The other place where unix shells have an advantage over Powershell is in there interface, as Powershell is currently quite basic in that department. There's limited tab completion and a prompt that can be altered (like PS1 under sh derivitives), but not much over that. Certainly nowhere near my personal favourite, Fish. 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. Why so closed-minded? Powershell has a lot of interesting ideas, and an architecture that's structurally very well organised. Don't dismiss it just because it was made by Microsoft, especially since it sounds as if you haven't even tried it out.
There are experimental shells for Unix that do that sort of thing; most of us just don't see the point.
http://geophile.com/osh/index.html
http://dispatch.sourceforge.net/
Things like 3D acceleration are decades behind Windows.
Actually, 3D acceleration in Linux is technologically ahead of Windows. What's behind is driver support, although that's coming around.
People use Windows because most people are not looking for the same things in an OS that you are.
Well, nobody in my family uses Windows anymore: they have all switched to either Mac OS or Ubuntu, both of which are considerably less hassle and overall cheaper.
Its the typical .NET deal. First time you run something it takes a bit, after that its instant.
So basically, what makes it suck less, is to use it more.
in the specific case of diffing the contents of two directories, it's just
$> diff --brief a/ b/
It just seemed worth pointing out.
I installed cygwin and hated it, installer kept screwing up, and it was really slow.
A dedicated ReiserFS partition with a Slackware 11.0 disto and installation of coLinux on Windows solved (almost) all my problems. Bypass M$ entirely, the freedom of bash...
(The only snag is that cofs isn't finished yet)
As for powershell, I installed it when it was in beta and still called Monad, year or so ago, I was impressed, but it seemed like a lot of COM bloat to me... (FYI, I hate COM/OLE from a programmers perspective)
There is no psychiatrist in the world like a puppy licking your face - Ben Williams
The FOR command in the "legacy" Windows shell is pretty powerful, too. It even has horrible syntax, just like its UNIX fathers.
Yes, the legacy Windows shell sucks, but not as badly as most people assume. The NT shell can do a lot of stuff that most people don't even think to try. Great gobs of functionality have been added over the years, starting with Windows NT 3.5. And contrary to what many slashdotters think, the legacy shell on Windows NT-derived systems is not DOS, nor is it 16-bit. CMD.EXE is just another 32-bit or 64-bit process running on the NT kernel.
While I can't comment on any of the rest of it. (Yeah, I work for 'em)
a milyID=c6ef4735-c7de-46a2-997a-ea58fdfcba63&Displa yLang=en
2 &p=1&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId= &u=%2Fdownloads%2Fdetails.aspx%3FFamilyID%3D6ccb7e 0d-8f1d-4b97-a397-47bcc8ba3806%26DisplayLang%3Den
2 &p=2&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId= &u=%2Fdownloads%2Fdetails.aspx%3FFamilyID%3D10ee29 af-7c3a-4057-8367-c9c1dab6e2bf%26DisplayLang%3Den
I can offer a link to the download.microsoft.com page that pulls it for Vista. (all links are English x86, if you run English x64, you'll be able to navigate the download center by now).
Vista x86: http://www.microsoft.com/downloads/details.aspx?F
XP x86: http://www.microsoft.com/downloads/info.aspx?na=2
WS03 x86: http://www.microsoft.com/downloads/info.aspx?na=2
Get it, use it!
-- I worked briefly doing part of the steps of release management for this, so it's cool to see that people are enjoying it.
I assert that my comment is only my opinion, not that of any employer, past, present or future.
Nobody is denying that Cygwin has lots of tools, and within certain applications it does just fine. But it is damn slow, a major hog and doesn't really give you the kind of integration you sometimes need. Let's not forget that a lot of those tools on your list can be found in native Win32 binaries, without the need of the cygwin libraries. I wouldn't dream of using Cygwin's awk when I can use the win32 one. Plus the fact that it does introduce some pretty peculiar incompabilities with some non-Cygwin apps that can be difficult to overcome.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Examples: Bash is pretty poor where your commands take more than one file and, to a lesser extent, where they produce more than one file. For instance if you have two directories a and b and want to do a diff on their contents, what do you do: /tmp/lsa /tmp/lsb /tmp/lsa & /tmp/lsb & /tmp/ls{a,b}
% mkfifo
% mkfifo
% ls a >
% ls b >
% diff
That's just disgusting.
Yes that is disgusting. Fortunately, you're not the first person to notice this. Try this instead:
diff <(ls a) <(ls b)
There is a similar syntax for outputs as well. It's not perfect: you can't easily generate a general directed graph, but in that case, you would probably get deadlocks anyway, since programs tend to read files in order.
SJW n. One who posts facts.
take a look at wwww.nsoftware.com and look at their remoting capabilities... powershell scripts can be extended to add cmdlets for ssh, snmp, wmi, etc... no reason perl and bash and ??? could not be added as another snapin to extend things...
another cool product is www.powergadgets.com for widget/gadget graphing on windows desktops...
sig goes here!
actually no because the power shell refuses to run things which are ambiguous.
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
Why are we talking specifically about Linux here? sh runs on every variety of *nix, has decades of techniques and development, and up until this latest effort by Microsoft, had absolute no competitor in the Windows world. Windows NT servers have existed since the early 1990s without a decent bloody command line. We've been forced to either use goddamn scripting languages like VBScript or go grab sh variants and kludge them into running on *nix.
.conf file, which I can open up in any goddamn text editor, modify and save, quickly test and quickly make an easily usuable back up copy. I can administrate a goddamn *nix box with ssh and a text interface, even when I'm forced to go over a dialup connection. The text editors are optimized for terminal usage, which is precisely why *nix kicks the shit out of Windows in the server world.
It amazes me just how little all the Windows advocates out there actually understand about the world of system administration and maintenance. They're so goddamn addicted to their little GUI tools, and yet they are so often forced to use substandard tools for automation. I'm not saying sh and its descendants are perfect, but compared to that worthless DOSesque piece of shit called CMD.EXE, they're like friggin' Einsteins compared to a low-level functioning mental retard.
I could give a shit about desktops, about whiz-bang GUI config settings. I find them so appalling inferior to a simple
Windows administration is an exercise in visual masturbation. It may take me a couple of hours longer to get Samba running, but management is infinitely easier. Follow a few basic rules about backing up conf files, and you can test things out, and if it doesn't work, just copy the backup conf file back, restart the Samba processes, and bang, all the evils you brought into the world just disappear. Windows and its advocates are based on the model that everything has to have fucking check boxes, radio buttons and drop down lists. I mean having to have a bloody script to control GUI apps is so symptomatic of the psychological disease your breed suffer from. Rather than learning how to function in an economical fashion, its all about finding reasons to justify the existence of a GUI on a server.
I won't debate that for Joe Q. Average, Windows is still at the top of the heap. But don't give me that shit about server environments, where the requirements are so different. I welcome the day when Microsoft gives me a command-line and simple scripting interface where I can modify any part of the system from a terminal session. But even giving us that won't answer horrors like the registry. How could you ever produce a CLI tool that could meaningfully control that. Guess what, on *nix boxes, it's as simple as vi, emacs, or even some Wordstar clone like joe if that's more you speed.
The world's burning. Moped Jesus spotted on I50. Details at 11.