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.
Named after the designer lost a testicle in a tragic chair throwing accident.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
is one of the nicest things that came out of Redmond. Ever. My only complain is that it is tight integrated to .NET, but OTOH I believe this is necesary to integrate the always nice C# to it, which is of course a plus.... You can't have the cake and eat it...
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
...in 20 years MS will invent UNIX.
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.
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.
Inconsistencies abound and everything is a special case.
You should switch to bash and the GNU tools.
Oh, wait.
Proud member of the Weirdo-American community.
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.
2017, the year of the linux desktop!
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.
Just remember - if the world didn't suck, we would all fall off.
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.
If this were Usenet, I'd killfile the lot of you.
What is wrong with Cygwin? How can he bash Cygwin (sorry, no pun intended) without even bothering to say anything about it?
Windows Powers Hell ?
I guess I always suspected it was true, but the beastie mascot of BSD made me wonder if there wasn't room for a little UNIX in Hades too.
Use the Firehose to mod down Second Life stories!
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?
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?
Wrong. 90% of users don't need the old windows/msdos shell. If people had a shell that was as good as bash, then they would use it. As it is now, using the shell in windows doesn't provide any benefit, so nobody bothers to use it. You can't say people don't need a shell when they don't have one. It's like saying people didn't need macros in word processors before the existed. Nobody used macros because the option wasn't available to them. Now that macros are available, many people do use them, and not just the power users. MS assumes that everybody is an idiot, and therefore doesn't provide tools that people with the right skills would actually use. Therefore, nobody has the opportunity to develop skills with these tools. Take a look at some of the stuff in XP, like that search dog, and the dumbed-down control panel and management options. With features like that it's no wonder people don't learn anything about computers, when the computer assumes they don't.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I would argue most power users don't need a shell.
.NET String object has an API that's a lot easier than sed and awk.
:-)
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
Saying you don't need a shell just means you have found clunky, typically inefficient workarounds, or you are just living without its benefits.
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.
Paying taxes to buy civilization is like paying a hooker to buy love.
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.
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.
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.
For those who haven never seen Monad in action and are quick to bash (ha! get it?) Microsoft's new shell, take a look at these two videos. You'll see that it's much more than just bash on Win32. In fact, if it ever catches on, it'll be Unix's turn to play catch-up, because some parts of it are pretty damn amazing. (Note that those are from 2005, but AFAIK, there haven't been substantial changes.)
:-)
The whole point of Monad is that it's not just text, it's objects. So, unlike Unix, where you work with a command and then filter its output (which is just text), the output of Monad, while looking like text, is actually kind of like pointers back to the real thing, so instead of just doing a Unix-style command | filter | filter, you can say "OK, run this command, now of the things it output, go back and tell me this and this about them." Like, "Of these things that are running, tell me which five are using the most CPU time, then tell me the version of each, and how much memory they're using."
PS: "...even if it does have a dorky name"--which name were you referring to: the one that sounds like 'testicle' or the one that makes me think of the Lottery?
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
I have to manage a Windows domain of a 1000+ users and Powershell (yes crap name) allows me to do stuff that you used to only easily do with expensive third party stuff quickly in a few lines. .Net, WMI etc. and it beats Active Directory administration through a GUI any day.
The only other choice to do something similar on Windows is VB script which I find painful at best. It may not be the best Shell ever but at the moment its the best Windows integrated shell with access to
The book is great by the way, and his blog has loads of useful tips too.
Anybody who is actually going to try it, will find the powershell community extension very useful. G
I hope this is not a dupe - I certainly was not aware....
l ogies/management/powershell/download.mspx
...PowerShell is avlaibel for MS OS's older than Vista too:
http://www.microsoft.com/windowsserver2003/techno
That's not an apples-to-apples comparison, though.
In cmd.exe, "dir" is "dir." It gives you a text listing of the files and subdirectories of your current directory. In PowerShell, "dir" is an alias for "get-childitem," which returns an object array that can either be parsed for display in the console, or passed down the pipeline to another commandlet.
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 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
- 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.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Yes you can, you set it in your Powershell profile, look for the function prompt.
[datetime]::now.ToLongTimeString() give current time btw.
G
The Bean Shell. That's it. That's what Gonad is trying to copy. Though I forget - who's trying to copy who this week?
Same problems too as well - memory consumption up the wazoo and slow as hell. Every time you've got to do a "pipe" you need to look at miles and miles of API.
Patriotism is a virtue of the vicious
It's that slow with a directory with only hundreds of files? I have directories with tens of thousands of files; I wonder how slow it would be with those.
Any sufficiently recent Microsoft OS contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Unix.
"Not an actor, but he plays one on TV."
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
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
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.
Linux already has lots of scripting languages.
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.
Oh man, are you bashing PowerShell there? ;p
'Yes, firefox is indeed greater than women. Can women block pops up for you? No. Can Firefox show you naked women? Yes.'
The default security blocks them. To run unsigned stuff, you have to set it to accept those scripts. Just a one line command you'll see at the top of almost any blog/tutorial posting on powershell, nothing painful.
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.
:)
I agree with this part:
anal sex is nice because it works on all genders.
Java, however, still sucks.
Its not so much dealing with a "smart CLI"—that the interface is a command line one is irrelevant—as dealing with "returning objects to an OO platform". Programs not designed to run on on OO platform (like anything designed to run on Unix or Windows but not something like
OO shells running on OO platforms will enable new ways of chaining programs together (not just from CLIs, either).
Well, sure, the
Thanks to some poor choices in my younger days, I have become a full-blown Microserf herding along 250 Windoze servers, half of them in remote locations. If I had it to do all over again, I would have taken the red pill. This may offend the *nix snobs here, but if MS gets really serious about MSH (the way I keep seeing it when running PowerShell), it will be awesome. I haven't seen anybody here mention that it is built-in with Exchange 2007 and when you run through an E2K7 wizard, the last step is the display of the MSH script that will execute once you click the Finish button. It's also just waiting for you to copy and paste that script before clicking the Finish button, so you can expand it and reuse it later.
My boss is such a Windoze junkie, he pooh-poohs my scripting efforts at every turn. We often spend hours and hours doing repetitive crap in the GUI's because "we don't have time to work out a script now!". I have avoided getting really deep into cmd.exe and VBscript approaches ever since I first read about Monad during the betas as that crap should be passing away. I've been bursting at the seams for some good books to come out.
Beware a first effort from MS. If they get serious, the third version will be quite good. In the meantime, a wise sage told me to expect third party vendors to jump on this bandwagon and cook up gobs of stuff to leverage the PowerShelll to save Win Sysadmins keyboard time with canned scripts. That would leave me sucking garbage in the MS Matrix with the rest of the Duracells, but fortunately my boss won't spend any money on decent tools, so I will get to hack out the scripts by hand and really learn MSH. Awesome.
If you're a Win Sysadmin reading this, be sure to check out http://www.sysinternals.com/Sysinternals and download the Misc utilities package, especially pstools.exe I use them all the time like a telnet session (via RPC) into remote PC's to clear up networking problems on them. netsh.exe then allows me to remove freakin' static WINS and DNS entries in TCP/IP properties, all without disturbing the user. It doesn't take long to learn and it saves gobs of time.
Now I need to get back to my Linux lessons so I can use some discrete Linux servers on our edge networks, then they can start appearing closer and closer to The Core.
In principio erat Verbum.
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.
Imagine someone gave you some library code, but to use the code you couldn't pass in variables, objects, or whatever. Each function in the library takes one input -- a string. The return from the functions are also one output -- a string. You need to convert this to/from any meaningful format in order for you to use it. That is bash.
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.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Actually, that is PowerShells biggest weakness as a integration shell.
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).
Just another "Cubible(sic) Joe" 2 17 3061
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.
I've been using PowerShell for a couple months, and it's definitely better than cmd.exe. However, it's really built more like an interactive scripting environment, with shell features left as an afterthought.
Only the most basic redirection is implemented. Basically you can use "> file", "2> file", and "2>&1". That's it. You can't create arbitrary fd's and dup them. It's like they didn't realize that the '1' representing stdout and '2' representing stderr actually mean something more general. Oh, and no input redirection. Trying to do:
somecommand < file
gives you this error:
The redirection operator '<' is not supported yet.
At line:1 char:14
+ somecommand < <<<< test.txt
Although you can technically use "2> file" to redirect errors, it's actually a big pain. Say your program outputs to stderr for various warnings, and you want to capture those. Well because everything is an object, each error line is converted to an ErrorRecord object, which is then serialized. Unfortunately, the serialization of an ErrorRecord includes a bunch of other clutter. Here's an example of one error line:
> perl -e 'warn qq[Something bad happened!\n]' 2> out.err
> cat out.err
perl.exe : Something bad happened!
At line:1 char:5
+ perl <<<< -e 'warn qq[Something bad happened!\n]' 2> out.err
Three lines for every error, with a bunch of clutter to make it hard to read. In order to get succinct log files, I had to write my own ErrorRecord converter to get back to the one line I want.
Command argument parsing is broken. The parser will split arguments that look like "-x12.34". So if you try to pass a switch with a floating point number as part of it, the program actually receives two separate arguments: "-x12" and ".34". You have to quote the entire thing to get it passed as one argument.
One major annoyance with cmd.exe that has not been completely fixed is the quoting inconsistencies. Nested quotes don't seem to work right. In most shells, single quotes prevent any interpretation of the string, which is mostly true in PowerShell. So when writing a quick Perl one-liner, I use single quotes to make sure any Perl variables aren't interpreted by the shell.
perl -e '$k = "hello"; print $k'
That seems to work, and prints 'hello'. However, try adding a newline:
perl -e '$k = "hello\n"; print $k'
Now Perl gives me a syntax error regarding the backslash, which leads me to believe the shell is interpreting the string before handing it to Perl. In this case, I can work around it because Perl has its own quoting operators:
perl -e '$k = qq[hello\n]; print $k'
But how would you pass a string like this to some other program where you needed the quotes? I couldn't figure it out.
As a scripting environment, it's pretty nice. And like I said, it is better than cmd.exe. However, basic shell functionality is semi-broken in many ways, because of the focus on Being Innovative With Everything As An Object.
PS. Don't forget that the escape character is ` (backquote), and not \ (backslash) like in every other shell/language.
--
Promoting critical thinking since 1994.
I wouldn't want to write an application with it because of the overhead, but for scripting (especially complex, stateful scripting) it just rocks.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo