Slashdot Log In
Windows PowerShell in Action
Posted by
samzenpus
on Wed May 02, 2007 01:51 PM
from the read-all-about-it dept.
from the read-all-about-it dept.
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Monad (Score:5, Funny)
(http://www.stileproject.com/ | Last Journal: Friday June 22, @03:09PM)
Re:Monad (Score:5, Informative)
PowerShell (Score:2, Interesting)
At this rate... (Score:5, Insightful)
Re:At this rate... (Score:4, Informative)
(http://lp.org/)
"Those who do not understand Unix are condemned to reinvent it, poorly"
Or, Greenspun's 10th Rule: (Score:5, Funny)
Re:At this rate... (Score:4, Informative)
Re:At this rate... (Score:4, Informative)
(http://www.int64.org/)
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".
Re:At this rate... (Score:4, Funny)
"Far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-eight million miles is an utterly insignificant little blue-green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea." (Douglas Adams)
Re:PowerShell isn't a Shell It's a scripting langu (Score:5, Insightful)
(http://www.weigel-mohamed.org/ | Last Journal: Sunday August 13 2006, @09:36PM)
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:At this rate... (Score:4, Informative)
The FOR command [microsoft.com] 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.
Re:At this rate... (Score:5, Interesting)
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
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.
Don't knock it until you try it (Score:4, Interesting)
(http://www.int64.org/)
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.
Re:Don't knock it until you try it (Score:5, Informative)
(http://www.thisismyown.com/)
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.
Re:Don't knock it until you try it (Score:5, Informative)
(http://www.monkeyengines.co.uk/)
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 [wikipedia.org].
Monads are windowless, get it? (Score:5, Interesting)
(http://ouij.livejournal.com/)
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 (Score:5, Funny)
You should switch to bash and the GNU tools.
Oh, wait.
Everyone should follow their lead... (Score:5, Funny)
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.
Great Review (Score:5, Interesting)
(http://www.therandymon.com/)
What is wrong with Cygwin? (Score:2, Interesting)
What is wrong with Cygwin? How can he bash Cygwin (sorry, no pun intended) without even bothering to say anything about it?
Some clever spacing (Score:5, Funny)
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.
I'd love Powershell, if it weren't for one thing: (Score:5, Interesting)
(http://www.dashmaps.com/)
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?
What about MKS? (Score:3, Informative)
The name PowerShell has been already taken... (Score:1, Interesting)
(http://freeshells.ch/~bsah/)
powershell - powerful terminal emulator for GNOME
Why is JPSoft's 4DOS/4NT not mentioned? (Score:2)
(http://clintjcl.wordpress.com/ | Last Journal: Tuesday May 09 2006, @07:45PM)
So, I've been using NDOS/4NT for almost 20 years now. Why would I bother to learn PowerShell when I already have a shell? And I already have cygwin, so I can use unix tools at the command-line just fine?
It's sad that more people aren't using this great tool.
A quick intro to Monad (Score:4, Interesting)
(Last Journal: Thursday July 12, @12:30PM)
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?
You can knock it but it IS VERY USEFUL (Score:3, Interesting)
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
FYI - PowerShell is not just for Vista (Score:3, Interesting)
...PowerShell is avlaibel for MS OS's older than Vista too:
http://www.microsoft.com/windowsserver2003/techno
Copy and Paste (Score:2)
(http://www.tobiasly.com/)
Even worse, all copy operations work on a rectangular block of text, not a true start and end point as in a word processor. It makes it useless for copying the output of a program (whether it be a long filename, URL, stack trace, etc.) and pasting it somewhere else.
When PowerShell came out, that was the first thing I tried, thinking for certain they would have fixed that. But they didn't. At that point I closed PowerShell and haven't used it since; I just stick with Cygwin or use Putty to SSH into a *nix box.
Prompt (Score:1)
(http://carnagepro.com/)
WSH since 1997? (Score:2)
(http://www.serviza.com/)
Windows Scripting Host (WSH) was released in like what? 1997? How is PowerShell any different than what you could do with WSH?
Bean Shell (Score:4, Interesting)
(http://www.badstep.net/ | Last Journal: Tuesday December 30 2003, @06:04AM)
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.
The early steam age of computing (Score:2)
Anyway I was there in SuSE CLI and fired up YaST 2 (MS speak: the SuSE Installer) in it's CLI version. And here it comes:
1) The characters wouldn't render correctly because the charset wasn't the right one.
2) I was logged in from OS X / Terminal and the keycodes from my Mac KB wouldn't reach out to remote PC SuSE with [fill in charset 'XXXX-uft8b32-centralusbekistany-ZZZZ' here] aktivated.
3) A pure real literal high-quality unobscured 'Ctrl-C' tranferrend via the context-menue option of OS X term (smart people these apple guys) didn't work either due to SuSE/PC/Whatnot keycode/charset/whatnot issues
I had to ask our Windows Admin next to me to log in via putty and to the install (duh.). Given, it was SuSE, it was 9.3 and it was totally bugged up. YaST 2 CLI sux and is no where near Debian apt or OS X Fink. [x86 Debian and OS X play ball very nicely btw. Great server/workstation combo]
But as long as I have to spend 40 hours fixing character renderings of a web application the only possible way that isn't even mandatory according to w3c standards adn evaluation and as long as the VI is the only way to be halfway safe to work over remote ssh and then only if im using the right keyboard and have the right charset (of a set of something around 60)
if it really was a hardship, put Windows in a VM (Score:2)
LoB
Wow! (Score:1, Troll)
(http://slashdot.org/)
*nix should do this too (Score:2)
(http://www.mobydisk.com/)
Digital signatures required for scripts? (Score:2)
effing objects (Score:2)
(http://www.soundclick.com/tsiangkun)
I for one like working with text, and could care less about wading through tons of API documentation for these wonderful pipable objects.
I have a myriad of OO and procedural languages for solving problems. My shell is the duct tape that holds them all together.
Windows is finally usable... (Score:1)
Documentation (Score:2)
Can powershell fix WGA? (Score:1)
(Last Journal: Tuesday February 25 2003, @02:24PM)
Managing hundreds of remote servers (Score:3, Interesting)
(http://www.sysinternals.com/ | Last Journal: Saturday August 21 2004, @11:11AM)
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.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.
A great command shell through an awful GUI (Score:2)
(http://www.windy.gen.nz/ | Last Journal: Wednesday January 05 2005, @03:37PM)
I've played with PowerShell a little, and it looks very impressive from what I've seen. The thing that's prevented me most from using it properly, though, is the same thing that prevents me from using the old Windows Command Shell -- Windows presents it inside an awful, inflexible window. It's impossible to resize horizontally, only goes a limited distance vertically, and it's very difficult to customize.
I'm sure there must be a way to use a Windows shell in a better terminal Window than that horrible thing that pops up by default, but I haven't been able to find anything yet. Can anyone suggest anything that's a bit more friendly for typing commands?
My favourite command shell in Windows is still bash through a Cygwyn-compiled xterm, which is good, but I'd really like to try out the interactive part of PowerShell properly.
ruby shell (Score:2)
It's funny that IT slowly goes back to ...LISP. (Score:2)
Windows Powershell is nothing more than a functional programming language environment where function combination is the primary means of making calculations. So is bash and almost every other command line environment.
Makefile tools are also mini functional programming languages. Make, ant, and other utils, are mini programming languages as well.
But so are text config files: they hold instructions for programs to use to alter their behaviour.
What about the hundred XML config files in various environments? And XML being used as a ultimate language for data transfers?
How about XPath and XQuery? aren't those language environments, as well?
Schema validators are also language environments.
What about scripting languages for applications? Monad makes the whole
HTML and markup languages are
DON'T YOU SEE A REPEATING PATTERN?
There needs to be a single language that unifies all these...that unifies data transfer between programs and machines.
The funny thing is that...
IT EXISTED FROM 1958!!!
and it is called
You ain't seen nothin' yet (Score:2)
Inconsistencies? Read "The Unix Hater's Handbook". It came with a barf bag pasted to the back inside cover. From that standpoint, it has been a blessing that the Windows shell has been a tiny subset of the UNIX shell.
Powershell DOS (Score:1)
Looks like cmd, feels like cmd... (Score:1)
Let me first say that the whole
Other than still looking and feeling like a cmd shell, it doesn't support some of the common things that I use in a shell....all of the time: CTRL-U to clear the line before the cursor, or CRTL-E to go to the end of the line.
Re:It's amazing people still use windows. (Score:1)
(http://cryptostenchies.com/)
Re:It's amazing people still use windows. (Score:4, Funny)
2017, the year of the linux desktop!
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: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:It's amazing people still use windows. (Score:2)
(Last Journal: Tuesday March 13 2007, @02:39PM)
Re:It's amazing people still use windows. (Score:2)
Windows got it's push from 3rd party money (IBM and others) thus adding to it's war chest.
Linux doesn't have the resources that Microsoft had to get it polished to the current level.
Re:9 years? (Score:1, Funny)
Re:It's amazing people still use windows. (Score:2)
(Last Journal: Friday May 18, @11:07AM)
Yes, that sounds roughly fanboi-ish, but it's a reflection of what I see in the world around me, not what I imagine. I recently handed Ubuntu CDs to two barmaids that were fed up with trying to get Windows for free as they can't afford the cost of a legal copy. They are not technically minded, they installed it themselves and are now very happy and not going back. A decision they made shortly after I gave them advice on what tweaks to make to Firefox... I see this being repeated all the time yet these people will not be counted in the desktop market share wars.
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.
The philosophy behind textual data (Score:4, Interesting)
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.
Re:The philosophy behind textual data (Score:5, Insightful)
(http://1-4-4.home.comcast.net/ | Last Journal: Wednesday March 01 2006, @03:16PM)
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.
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:It's amazing people still use windows. (Score:2)
This is one of the few times i can say, i honestly don't know if you're trolling or not, and i don't mean that in any way an insult. Maybe it's a statement to your relative subtlety
People like things simple, but many things are complex. OS adoption is determined by many factors, technical excellence just being one of them. Consider something "simple" as price?
I could got on for a paragraph or two just on price alone. Early adoption is done by people who have a whole different class of requirements than the mass market. The fact that Linux is going into the mass market at all is a testament to its usefulness.
Re:It's amazing people still use windows. (Score:2)
(http://go.org.nz/~corrin)
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:
% mkfifo
% mkfifo
% ls a >
% ls b >
% diff
That's just disgusting.
And control of GUI applications - KDE is a quite nice scripting langauge but it isn't a shell. Bash has virtually no gui scripting and I'd call its tie in with KDE's scripting poor - only the most basic datatypes can be exchanged.
Compare to applescript for an example of a fairly powerful modern scripting system.
Imagine, a whole post on the deficency of the unix shells and I didn't even mention my pet hate of escaping!
Re:Windows "power shell"? (Score:5, Interesting)
(http://1-4-4.home.comcast.net/ | Last Journal: Wednesday March 01 2006, @03:16PM)
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.
Re:Windows "power shell"? (Score:5, Interesting)
(http://1-4-4.home.comcast.net/ | Last Journal: Wednesday March 01 2006, @03:16PM)
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.)
As long as Monad has that, it's probably decent. But that's going to be application-specific.
In what sense is Monad's pipeline communication format "application-specific"? It can deal with any
Re: Windows "power shell"? (Score:5, Insightful)
(http://www.dolda2000.com/~fredrik/)
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.
Re:Come one, sell me this shit. (Score:5, Insightful)
(Last Journal: Thursday May 24, @01:08AM)
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:It's amazing people still use windows. (Score:2)
(http://integramod.tripod.com/)
Any more stupid questions?
Re:one nad? (Score:2)
Re:it's obvious THAT YOU ARE A LINUX TROLL (Score:3, Informative)
(Last Journal: Tuesday March 13 2007, @02:39PM)
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.
Re:but those only get you so far (Score:2)
(http://1-4-4.home.comcast.net/ | Last Journal: Wednesday March 01 2006, @03:16PM)
Anyone else wonder what this means? I guess the question is, where do those leave you unsatisfied? To my knowledge, these (cygwin, active perl, etc) integrate with all features of windows...including, but not limited to, native features like COM objects.
So what basis in fact does this statement have, if any? Sounds like Microsoft-funded propoganda.
Why does the shell need to support data exchange between programs? Well, that's the whole idea between Unix pipes. Bash supports text streams (or rather, byte streams commonly assumed to be textual) between processes, and that's it. And that could be enough - given a universally respected set of conventions on how to format and identify datatypes. So if ActivePerl gets some nice chunk of data out of a running GUI application, and at bash you're trying to pipe that data output into something else - there's a rather cumbersome process of turning that Perl data into a raw bytestream and turning it back into useful data again. The complexity of this problem depends on the complexity of the data - and bash's willful ignorance of the significance of the data that goes between processes means that it can't help in any way.
What's specifically missing is shell-level support for interacting with GUI applications at the same level that ActivePerl is capable of. Bash's support for datatypes isn't sufficient to make it a good way to interface with scriptable applications.
A statement like "but those only get you so far" is a bit vauge - but I think I can see the point.