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!!
Nah, they just want every OS to be like Vista.
Clicked pie.
...in 20 years MS will invent UNIX.
Every time I use Windows, I find it amazing that people still pay for and use MS software. It's pretty good, but it seems to be missing a lot of key features. Things like the shell are decades behind unix. I can't even take a picture and scale it to fit on the desktop without the aspect ratio being messed up. I can't stand using IE, even IE7 because it's behind where firefox was 2 years ago. given the current rate that Linux/Open source is catching up to MS, I give them another 10 years before linux has 20% of the PC market.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
If he wants a powerful shell program, he can go back and use OS/2 with its builtin REXX, or he can get an addon REXX for windows.
Now all we need is for Sun to develop a Solaris-only shell, Apple to develop a Mac-only shell, and RedHat to develop a Linux-only shell. I hate re-using code because it forces me to solve new problems every day. I'd rather create new value on Mondays only, and then spend the rest of the week re-doing the same work on my other platforms. It gives my mind a chance to rest, and I can drink heavily mid-week and still be able to do my job.
I sure hope they charge extra for it, make it a resource hog, lock out third-pary extensions, and then discontinue it as soon as I'm dependant on it. I really liked the 1980s and look forward to reliving them.
I 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.
Stop trying to fix windows and switch to linux. Windows is hopeless. If you can't run linux then you might as well end-it-all now, because you life is not worth living.
With their own NIH sudo and sh variants Microsoft are well on their way to reinventing unix.
Will I be able, within simple customization use my Bash scripting in Windows powershell ? /home/user folder, I will change it to c:\ or c:\documents and settings\user) only.
:)
Simple customization such as folder changing (if it's hard coded to
If so, and Bash scripting might actually work, it would be great for me so I won't have to suffer while I'm using Windows, well, atleast not from the powershell... BSOD's Still disturb me
Read and Comment at my BLOG
!!!
What is wrong with Cygwin? How can he bash Cygwin (sorry, no pun intended) without even bothering to say anything about it?
"Stop trying to fix windows and switch to linux. Windows is hopeless. If you can't run linux then you might as well end-it-all now, because you life is not worth living." - by jcgam69 (994690) on Wednesday May 02, @03:15PM (#18961063)
SILENCE, PENGUIN TROLL!
After all, You were the one foolish enough to choose the underdog, now, live with it.
(Yes, you live in "linux land" and I will stay in Windows, the most used Operating System on the planet, & all the way from the home level, to departmental servers using client-server mode, to the HIGH end, in Enterprise Class 24x7 stable operation (or, isn't NASDAQ going high-transaction, 24x7, evidence of this?)).
That all said, gee, one wonders: If Windows is used more on all of those levels, and it is? Where is the greatest chance of earning monies then? Answer - Windows.
15 years now, and Linux still has not toppled Windows as the most ubiquitous and flexible environs there is, with the most peripheral device support (not meaning cpu platforms it ports to, but devices one can attach to a computer), and most surrouding software for various purposes.
Heck, Linux hasn't even "taken out" the other UNIX variants!
And, before you say "Windows has bugs/viruses/trojans/malware" etc. et al, remember, so do the others & it is just that they are not as targetted because there is less attack surface out there since they are less used & most of them are the result NOT of the Operating System Windows itself nowadays, but moreso in applications that ride on it (such as IE, when it is NOT secured by turning off JavaScript/ActiveX control usage/ActiveScripting).
(Besides, look @ the 'bright-side' of bugs: Techies love those same bugs/virus/trojans/malware, because it keeps them in a job - think about it!)
Performance of cygwin is abysmal. Actually not cygwin per se but the whole XP in which cygwin works ...
... The cost of processes ...
Same machine, same task:
XP+cygwin over 3 minutes
FC3 less than 3 seconds
Task involved greping and seding an processing hundreds of files
and files in XP killed 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?
''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.''
Those only get you how far exactly? With a Unix shell (Cygwin/MSYS) you can do all the unixy things you want. Perl is a complete general purpose programming language. If you don't like Perl's abominable syntax, there exist Windows-centered programming languages that can be used in place of scripts too, like Visual Basic, VBScript and JavaScript. Note that two of these are already supplied with Windows and the other is a Microsoft product too.
So as it stands, I simply don't see what use Powershell has. There are plenty of good tools available already, some of them free and open source to boot.
I'm guessing a lot of people are going to be nodding (or modding) in agreement, while typing away on a QWERTY keyboard, misspelling words in English (that language where spelling makes no sense), measuring things with the Imperial system, ...
harry@satan:~$ apt-cache search powershell
powershell - powerful terminal emulator for GNOME
It is a hog at best, and at worst when you are using it semi-heavily it can easily chew up 1GB of memory.
1GB for a command interpreter?
Christ.
I mean, just...
No, I can't come up with words that are strong enough.
Holy mother of Moore, they've got good crack in Redmond.
I guess we should throw out Chomsky's contributions should be thrown out, too. Fool.
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.
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
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.
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
Does that mean the 40 gig file I can pipe to a Unix command is passes as an object in PowerShell, and maybe loaded into memory first? ;-)
Other than that it might prove really useful. I have often looked for some way to simplify the piping in unix without having to play with sed/grep/awk to much and hope the command output doesn't change in future versions.
Microsoft has of course the advantage that they can define the object format in-house.
Maybe one should have a look at such a format for oss software (<cheesy_buwwzord> maybe an xml schema</cheesy_buzzword>), and creating additional objout/objin pipes in addition to the stdin/stdout ones.
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
Someone wake me up when they put out a shell that will run autoconf successfully. The day I can just run "./configure; nmake; nmake install" will be a happy day indeed.
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.
The thing that absolutely drives me nuts about both the Windows Command Prompt and Power Shell is its inability to copy a multiline string to the clipboard as a single line. For example, when the output of a command wraps from one line to the next, trying to copy that output will leave that embedded newline intact.
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.
Can the prompt be the present time ... like my bash prompt?
MS should get a pair.
It looks like you are using ps. ps on Linux can give misleading memory usage reports. Specifically, it counts the entire shared library against every process that loads it. For a program that loads shared libraries, like bash, this results in a significant memory allocation that isn't "real". If one copy of bash was the only program on the system, then bash would use 1 GB. However, 3 copies of bash, don't use 3 GB. They use much less. Additionally, if the same shared libraries used in bash are used in any other programs running on your system, and on Linux they probably are, then the total memory allocation falls further.
This website explains the problem better: http://virtualthreads.blogspot.com/2006/02/underst anding-memory-usage-on-linux.html
This is a well documented bug. I don't actually use a Mac, but likely the Mac O/S running bash exhibits the same behaviors as Linux.
It's worth noting that Chomsky's classifications of formal language types doesn't constitute a programming language. Which was the point of the original poster's remark, whatever you think about it.
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
Text is universal, though, and it lets you have a single means of output for simpler programs. Want to read the results immediately? Just call the program. Want to save the results? Dump them to a file to review later.
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.
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.
Windows Scripting Host (WSH) was released in like what? 1997? How is PowerShell any different than what you could do with WSH?
Expect Freedom.
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
I had a project that required me to start and stop a Flash application from a very slightly modified UNIX daemon process in Mac OSX. I was unable to figure this out going through the command line.
... command line" the exact opposite of what I need.
I can do "open flash_application.swf" in a command shell from the daemon process, but the "open" command detaches completely from the shell and doesn't provide any type of handle to the launched application. What I would love would be to use the original UNIX code that simply does a "kill $flash_pid" but unfortunately, "open" doesn't shoot back the pid.
You seemed to know a bit about Max OSX, so I ask here. Google gives me a LOT of false positives that go something like... "how to do... without
Thanks in advance.
PS: For those who don't know: open is equivalent to double click on the file, the OS automatically finds the assigned application and runs it feeding the file. And fyi, the application can't be run from the command line and fed the file manually, the shell doesn't see it as a command line executable nor does it attach the application to the user GUI screen if required.
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.
Just reading the comments here emphasises what I think of todays state of IT: We are still in the steam age of computing. Wether what moves around in a CLI is streams of text or a bunch of objects doesn't really make a difference. Just today I was trying to get SuSE Linus to install mc over a remote ssh connection. [Sidenote to Windows-only people: Doing this sort of thing in the MS world still is factually impossible]
... as long as we're actually still working this way and this way is the most effective possible (as mentioned earlyer, we are way out of Windows league here) - we are still in the early steam age of computing. I predict it will take another 20 for this crap to finally iron out and everyone is using Bash or ZShell, keycodes and charcodes and glyphs are all in line and everyone not using the standard gets fried by pure marketforce. Sort of like the automobile industry today. ... But as I said: IT still is in the steam age.
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)
We suffer more in our imagination than in reality. - Seneca
I agree. I particularly like Windows DRM. I feel safer knowing my OS is phoning home to MS every 15 days or so.
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."
Because, otherwise, I forsee a Cease & Desist letter in their future, even if they had the name first.
Want to help me write it? I have ideas and enthusiasm at this point - not much else. Talk to me if you're seriously interested in making it happen.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
The Z-shell has had dynamic loading of extensions for about 10 years now. I suppose someone could have added GUI extensions that way. Maybe they have, I haven't checked on their development in a long time. Basic textual zsh works perfectly for me.
Glad to see though that Microsoft Windows is finally catching up to old technology in this area.
Why would this author not have put Windows in a VM on Linux years ago if it was that big of a deal? Sorry but that bit just sounded kinda strange but my guess it was all just to make it sound like he's a real programmer or something.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Probably painfully slow. I don't know enough scripting to actually benchmark it ... but on C:\windows\system32 (> 2k files) "dir" via CMD was done in well less than two seconds. After two seconds, PowerShell was barely up to the letter C.
.NET object. You just can't do that with CMD.
... well, stellar). It's a very powerful tool at only a 1.0 implementation, so it'll only get better... /Posting anonymously not because I'm an MS shill, but because I don't want to sacrifice my mod points on the article.
But, as another poster mentioned, with the performance hit comes the ability to treat each item returned by dir as a
Still, if all you need to do is list a directory's contents then you don't need PowerShell. With PS I can -- from the command-line -- manage remote computers via WMI (and let me tell you, the occasional ability to troubleshoot remotely without firing up VNC is stellar), with some custom scripts I can manage Active Directory (having to simply type 'add-employee "Joe Sixpack"' is
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
Wow, so you're telling me that Vista not only has UAP (finally, an OS with fancy user permissions!), but also has a programmable shell!?!?!? WOW, I had no idea OS's had progressed so far. Wholy crap, sign me up!!!
Love many, trust a few, do harm to none.
We all have one, it's called Groovy - a Java-based scripting language that steal functional tricks from elsewhere.
And I can use it on any platform.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Exactly. Everything you could ever need to do on Linux, you can do from the shell if you know the commands. Windows? Most programs don't take command line arguments or run in command line mode. That's part of why cmd.exe is so useless. There are no apps that make use of it. There's also the lack of things like grep, sed, etc. in the cmd.exe that make it useless. Bash has all of that, and it has had it for ages. The PowerShell is just MS trying to make an actual useful shell like we have because the old one was so bad.
look! it's a bird, it's a plane, it's....a girl? yes, a girl browsing Slashdot on Linux
Of course, this amazing textual thing would be fine, if only it wasn't for the fact that unix decided to allow spaces in file names, which means I find many of my scripts designed to loop over a group of files end up producing bizarre error messages whenever there is a file with a space. This is fixed by Powershell.
Just as it is fixed in a shell by anyone who can use the " character. I have written many shell scripts that are fine when encountering filenames and directory names with spaces, which I use all the time.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Let me give an example: one that I contend could be made easier to handle by using a "modernized" and object-oriented command shell.
Suppose I want to iterate through audio files on the filesystem - get "title" metadata from those that have it, and the length of the audio in time units, format that into a list structure and save it in an environment variable. Now, with bash, I'd either need one command capable of doing this task with each of the various audio datatypes on my hard disk, or else I'd need to switch between the various file types and run the appropriate command.
Now, object-oriented shells won't magically solve all our problems - for instance, if an object for some reason decides to call its "title" field something else - or if a format doesn't have those fields (C64 SID files might have a runtime field - but that was added as an extension, so maybe not) - but the OO solution would be to ask each file for this information.
> $data = for f in (find
Presumably that would return some nil objects in one or both columns depending on what files are processed. But that's the general idea. And then I'd also like to be able to do this:
>
Seems like a nice idea to me. The Z-shell has had dynamic loading of extensions for about 10 years now. I suppose someone could have added GUI extensions that way. Maybe they have, I haven't checked on their development in a long time. Basic textual zsh works perfectly for me. Interesting. Perhaps you could enlighten me a bit as to what these zsh extensions can do? As I said I have this project that's been mulling around in my head for a few years now, for a Linux shell with similar capabilities to Powershell - and in order to justify that work and to direct in sensibly I want to have a better understanding of other shells and operating environments, what they have to offer and what went wrong. I believe in the ideas I'm advocating here, but I also know I can't take them for granted - if I fail to adequately understand Unix then I, too, am likely to reinvent it badly.
I would say I am skeptical of what a zsh extension can accomplish. Sure, a shell extension can add new functions to a shell, but how does that help with the problem of improving command pipelines? How does that help me not to forget to account for the possibility that "find" could return filenames with whitespace in them, or that a field in a character-delimited file could contain the delimiter? Or if it doesn't do that, what does it do? Glad to see though that Microsoft Windows is finally catching up to old technology in this area. Whether they've "caught up" or "caught us snoozing and lapped us" is a matter of preference, I suppose. I think it also depends on how nice the shell is to actually use. I find the high degree of verbosity in the command naming rather annoying, actually - I suppose that probably helps with L10N but I am used to CLIs being rather more compact. But in terms of functionality they've provided something that I have a strong desire to see realized on Linux.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Sort by name:
du -x / | sort --method 'toString'
Sort by size:
du -x / | sort --method 'getSize'
Why is what you propose any better than simply defining new flags on du? If you have to add a new method to du, you can just as easily add a new flag. Then you don't have to have wordy --method arguments everywhere, you use flags like "-x" on DU or other applications.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
CLR objects can have string conversion methods if you want to output them as text; you can convert between text and binary and back in a way that's in fact more elegant than the Unix manner (where frequently parsing code ends up rewritten multiple times). I really don't see what we lose by moving to the Monad model.
I think we have crusty old 1970s shells with a veneer of tab-completion and command history added for convenience.
I think it's kind of a drag that Microsoft may now have a better CLI than Linux ...
You will feel better if you think about it a little longer. Really. I'm not sure what you mean by "wrangle live .NET objects and complex datatypes" but I do know that programs can be written and called that do exactly the same thing, with pipes even, without bastardizing bash. Talk about "new techniques" and "dot NET" gives me bad flashbacks to ten years ago when someone tried to give me VB religion. I'm glad I avoided that and this new "Power shell" looks like a second rate bash with a second rate tool set.
Friends don't help friends install M$ junk.
This is fitting. M$'s value is all a matter of perception, which is why M$ spends a billion dollars a month on marketing. Without that perception, there would be no windows.
Still, I like the original name, MSH (warning: Fake Community Effort) better. MSH can and should be parsed as "MicroSoft Hell" and it reminds you of the DOS toupper roots of it all.
Friends don't help friends install M$ junk.
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.
You've always been able to pick a simple delimiter when typing an expression like `s/old/new/' used in sed or ed - `s;o/l/d;n/e/w;'.
Lastly, non-linear pipeline syntax does exist and is not a new feature either. Zsh uses something like <(process1) and >(process2) for command splicing.
It woudl be nice if *nix commands offered standardized extensible input and output formats like what Powershell has with objects. Sysadmins write commands using pipes to connect processes together, then later when you upgrade the OS your scripts break because the format varies ever-so-slightly. Worse yet, without a standard error reporting mechanism nothing ever knows. The script can't tell "file1.txt 12345" from "error! 12345" so it just carries on with invalid data until somebody notices.
I remember reading once that Monad requires all scripts to be signed by a key countersigned by a certificate authority. Is that still true? If so, Monad is completely useless.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Is there going to be an IDE for writing shell scripts now ?
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.
I don't think being able to interact with the GUI is important though, or even a good idea; I just think that objects are a much better way of passing data around than text.
Also it's not quite as drastic as you or the OP would make it seem. bash so good for those complex one liners where you have to start messing around with sed; but if you're writing a script and not just using the CLI on UNIX you have Perl, and usually Python and Ruby too, available at your fingertips. Often whenever you need to script something and bash isn't quite up to it Perl fits in nicely.
I would say that Microsoft has brought out some really great ideas in PowerShell, and it's exciting that this is in direct response to Linux's capabilities, but I don't think it's as bad as you've made it out.
// MD_Update(&m,buf,j);
It's not just catching up, it's leaping ahead. Yes, it's a big surprise to see MS do this after putting zero effort into their shell for so long, but I'm increasingly convinced that the Monad way of doing things is intrinsically superior to the Unixy way. In particular, it will finally allow smooth interaction between CLI and GUI applications, which has never been feasible with the unix text stream model. Notice how modern Unix is neatly split into a CLI world and a GUI world, and the only connection is that some (usually crappy) GUI applications are wrappers around CLI ones.
Also, to add, the reason Unix can't do something like Powershell is that the fragmented Unix world can't unify itself around a component standard like CLR.
I've yet to come across anything that's more rampently homosexual than, 'Fiesty Fawn'. What could possibly be more gay then the innocent face down ass up mangina kawk fodder that is the Ubantu mascott.
u buntu%20feisty%20fawn&ie=UTF-8&oe=UTF-8&um=1&sa=N& tab=wi
Take a look at the google image search for 'ubantu fiesty fawn':
http://images.google.com/images?hl=en&resnum=0&q=
wow
who ever came up with this idea didn't see it coming cause they were facing- the other way
you can use 'ls' in a shell!!!
I tried running Powershell a while back after getting frustrated at how awful cmd.exe's scripting capabilities are in comparison to my usual environment (bash, in linux). It wasn't terrible, but I can't ever see it taking off. There's practically zero useful documentation to explain how to use the shell beyond the very basics. It also doesn't seem possible to get it to run older batch files (I have a few of them that are necessary for my job and I don't have time to rewrite them all), and I couldn't figure out how to set environment variables either. I'm sure that a lot of the things I was unable to get Powershell to do are actually very easy, but when there's no documentation available it might as well be impossible.
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.
Leaping all the way ahead to imitating AREXX on a late '80s Amiga...
"I've got more toys than Teruhisa Kitahara."
"Those who fail to learn the lessons of Unix are doomed to re-invent it. Poorly." -- Forgot who said it.
Somebody in marketing?
Uh do you really not understand the difference between a typeless language and an object-oriented one, or are you just trolling?
They kind of have already done that. Well, at least they developed a UNIX operating system (maybe sold is a better term, but it was 16bit and back in the 80s). The Windows NT kernel is basically VMS, which is essential UNIX. Again, though there are too many qualifiers to be having this discussion (I've realized this as I've been typing). I'll shut up now...
"but those only get you so far" Huh??? WTF???
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.
Put quotes around $file and ${file%avi}mpg like "${file%avi}mpg" and yes it will.
My biggest complaint about PowerShell is that I don't dare adopt it. I've still got a few Windows 2000 PCs kicking around at work (as machine controllers, so upgrades are a real bear), and PowerShell already doesn't support Win 2000. And it looks like the next major release won't support XP. Microsoft will use this as a tool to drive upgrades, just like they do with everything else.
:-(
This really annoys me, too, because it looks like PowerShell might do some legitimately interesting things.
Sometimes, Microsoft is their own worse enemy.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
"For two decades I've hated the command prompt in DOS and Windows."
http://www.jpsoft.com/
I find it VERY difficult to believe that someone that claims to have 20 years of experience with DOS and Windows at the command line could not know about their products. At one point, a version of 4DOS was bundled with Norton Utilities (called NDOS, as I recall).
"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)"
Yeah, if you spent the past 20 years blithely ignoring native software development on the PC platform.
Sounds to me like the submitter has been waiting 20 years for Microsoft to natively implement Bash under Windows to his satisfaction, and thinks PowerShell is it.
Or, he's just astroturfing, which seems far more likely.
My Windows Genuine Advantage must be broken. I tried to download powershell from the Microsoft site, but it said I needed to first validate my copy of windows. Maybe after I install powershell windows will remember one of the last two dozen times I validated my windows copy?
Actually, it was always 4DOS. Norton licensed the code from Rex Conn/JP Soft, tweaked it a bit, and called it NDOS.
4DOS rocked. I used to be a 4DOS junkie. There are still some things it did that I miss in 'nix today. I'd love to be able to license 4NT for work today, but sadly, the price isn't worth the benefit. Besides, these days I spend half my time in 'nix anyway...
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Perl can invoke all shell commands too by placing backquotes (or using the qx operator) around them just like a regular shell: ``
ls -s | lpr
this seems like a bad way to go about it:
"ls | select fullname,length | sort name | format-list | out-printer"
ls -s prints the size and the name, and it sorts by name by default, and it's formatted nicely already. You might mean one per line, in which case:
ls -s1 | lpr
What in the name of fuck are you talking about? I can take a twenty year old sh script and run it with almost no difficulty on damn near every variant of *nix out there. I get the feeling that a lot of you guys have done almost nothing in *nix shells, and are just repeating the sheer crap that comes out of Redmond. Christ, if there's one thing that has been pretty goddamn standard in the *nix world, it's the Bourne fucking shell.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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 don't you look up what CLR is before mouthing off?
Bizarrely enough, I can kick off Eclipse (disabling bytecode verification and fixing the memory to 256MB), and it takes almost a long as starting a new shell instance...
Not apples-to-apples, but I'm still really surprised (and disappointed) that the PS doesn't start up much faster...
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.
>I haven't used it enough to speak to how it works in practice >That's what they said about the early versions of Java. Now C++ is relegated mostly to embedded, systems and games programming. Java has its uses but it is yet to replace C++ as language of large software systems due to lesser flexibility then C++. You obviously like to speak of things that you haven't used.
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.
Using objects is a very bad idea because the object itself is application specific. I don't know why everyone is acting like this Powershell interacting with objects is so new. I am dealing with the WebLogic Scripting Tool (WLST) these days which is a Jython interface to a bunch of Java APIs. I'm interacting with objects from a scripting language, and it totally sucks because my scripts don't work from one version to the next. This problem can still occur with UNIX: if you can the format of your text, your scripts are going to break. However, the very act of having to convert data to text makes you *think* about how that should be represented. It's a barrier between the internals of your application and the external world. If you expose your internal objects directly to scripts, then any internal changes you make are going to break scripts. Believe me, those internals change a heck of a lot more often than you would like them to. If you don't allow them to, then you unnecessarily burden your code with backward-compatibility problems, which is exactly what got MS' code into such a horrible state.
Microsoft has actually come up with a way to manage system entities as full-fledged objects in a character-based environment using a simple command set, ...
As opposed to any normal script that can conditionally call normal programs that manipulate files or streams while also giving helpful output on stdout and stderr that the operator and machine can interpret? What revolution is M$ producing here again? What useful thing will this do for user or machine? Really, I'd like to know what the hype is about to cure my "unfortunate ignorance".
Friends don't help friends install M$ junk.
What on earth are yout talking about??
In all my months (both years, actually) that I have used PowerShell, I used it for its user interface, not for scripting.
And I used it in such a way that every command, piped to every command, worked in sensible ways.
Querying a list of objects results in a list of objects. You want text? Great. PowerShell bent over backwards and stuck its head through its legs and kissed itself in the crotch to give you clean, human-readable text out of your objects. But they're still objects. So you can introspect the properties of those objects. Or you can execute methods on those objects.
With only text, you just have a bunch of ASCII characters, that HAPPEN to line up in a pattern that can be read by a human or, with some effort, with a textual analyzer pattern.
But with objects, you can fire off commands that make sense because they are complete representations of WHAT THEY ARE, not how they are described in sequences of ASCII characters.
I'd love to see a rip off of this but with a ruby-ish type shell.... with the object orientated uniqueness....
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
REXX in OS/2 could interact with the GUI objects. You could also use IPC mechanisms such as semaphores, communicate over sockets etc. But yes, you are right. I remember that you could create "install" scripts in REXX which would create icons on the desktop, setup shortcuts etc using the OS/2 presentation manager objects.
Unfortunately no such thing exists on Linux/Unix. You are right - most of the shells we have on Unix/Linux are not substantially different from what was available in the 1970s.
tracert slashdot.org | clip
:(
Too bad if it's something already on your screen that won't help
Yes, yes they are. And they *still* get slated from half the Linux community.
"Windows sucks, it doesn't have a good shell!"
to
"Windows sucks, because although they built a good shell they copied it from us!"
How many people can read hex if only you and dead people can read hex?
Why is everyone comparing this thing to bash? There are many other good Unix shells out there as well.
For example zsh. It has
1: Programmable command-completition with out-of-the-box support for over 300 commands.
2: Memory overhead less than 640k.
3: Spelling correction.
4: Aliases.
5: Themeable prompts.
6: Improved variable handling.
7: Editing of multi-line commands in a single buffer.
8: Full customizability.
If this PowerShell can give me all of those and run on Unix, I'll definitely give it a shot.
That's why I love PHP, print_r('$whatever');
Do you really not understand "smooth interaction between CLI and GUI applications" or are you just a cockhead?
> The reason in Linux you use Bash for scripting is because it's convient.
The thing is, I mostly *don't* use bash for scripting, certainly not for anything over five or six lines. There are a variety of reasons for this, but the long and short of it is that it's more convenient to use Perl.
I use bash daily, but almost exclusively as an interactive shell, i.e., to run one command at a time and see the results. That's really what shells are good for. A shell doesn't need to be a good programming language. If I want a programming language, I'll use one that was designed for that purpose.
Cut that out, or I will ship you to Norilsk in a box.
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.
Actually, I believe imagery is more universal than text. There is interesting, recent research on this. Google for 'IKU'.
What about cfengine. Although it is meant to administer several computers at once, is that a lot like PowerShell?
There is also an open source PowerShell project in existence for 7+ years. See http://powershell.sourceforge.net/
It is very funny that the first programming language invented is the language that all other languages will eventually be turned to.
.NET available at the command line, which means we can communicate with applications like Word and Excel not only using VBScript, but the whole .NET as well, from the command line.
...programming languages as well. What about all the million communication protocols that exist out there?
...LISP.
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
Text is universal because the small graphical constructs that we use to form words are the smallest convenient building block we have come up with. They are quick to use and evolution of them for handwriting made them efficient to group together.
Things like having an individual symbol for every command would result in needing about 2000 symbols for the binaries on my system.
I might be agreeing we have made text universal sort of. But the reasons are complex. And text after all is actually a specific set of graphical symbols. So each word is only equivalent to a more complex glyph we have just adopted a seemingly efficient and compact approach to constructing complex symbols from atoms. And with things like tab command line completion it becomes really swift.
"For two decades I've hated the command prompt in DOS and Windows. Inconsistencies abound and everything is a special case."
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.
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.
One possibility would be to provide a text-based registry editor in the style of sql*plus or similar tool; you could even use a SQL-like syntax with selects, updates, inserts and deletes. Or failing that, something more like an LDAP interface, as the registry's hierarchical nature arguably mirrors that of an LDAP server more closely than an RDBMS.
Hell, if you really wanted you could write a text-editor style tool that understands the registry and exposes an interface to it that makes it look like a flat text file. Throw in some navigational controls (via keyboard shortcuts or vi-style commands, naturally) and it might just be workable. You could even have it able to collapse and expand sections like (eg) IE does with XML files, or have it navigate between nodes like info does.
I appreciate that you hate the registry (and I don't entirely blame you), but that doesn't mean that a cli-based management tool can't be written for it.
It's official. Most of you are morons.
Better is the enemy of good.
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.
Just downloaded & installed PowerShell. First command I tried was cd\ (I never type spaces), it would work under DOS, PowerShell didn't like it. Think I'll stick with DOS for now.
Powershell is powerful, but (IMO) anything that looks or feels like the old (and really crappy) cmd shell still needs some work.
.NET environment is fantastic. I especially like the apparent ease with which languages are integrated (IronPython, Boo). Powershell has good integration with .NET...I _really_ like the built-in XML parsing capabilities...a LOT!
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.
"...The smart and lazy ones I make my commanders." - Erwin Rommel
Using objects is a very bad idea because the object itself is application specific. I don't know why everyone is acting like this Powershell interacting with objects is so new. I am dealing with the WebLogic Scripting Tool (WLST) these days which is a Jython interface to a bunch of Java APIs. I'm interacting with objects from a scripting language, and it totally sucks because my scripts don't work from one version to the next. This problem can still occur with UNIX: if you can the format of your text, your scripts are going to break. However, the very act of having to convert data to text makes you *think* about how that should be represented. It's a barrier between the internals of your application and the external world. If you expose your internal objects directly to scripts, then any internal changes you make are going to break scripts. Believe me, those internals change a heck of a lot more often than you would like them to. If you don't allow them to, then you unnecessarily burden your code with backward-compatibility problems, which is exactly what got MS' code into such a horrible state.
The new bit is that this isn't just a new scripting language or programming language, it's designed for interactive sessions, too. It's a tool that could be used equivalently to a Unix command shell - a general-purpose CLI. By contrast, scripting languages usually have their own "program state" of variables and whatnot, while files and outside programs are considered foreign territory in the language's syntax. A general-purpose CLI on the other hand, is a language in which the filesystem and outside executables is part of the program state. Executables on the path serve rougly the same purpose in Bash as Python modules do on the Python module path (though you don't have to 'import' them, of course) - it's your set of tools for that language.
/etc/passwd still has a password field even though no one uses it these days.) You could use a higher-level metaformat like XML and still you'd need to stabilize the format and tagging of the important fields, or you will hit the same compatibility that you cite - which are the result of sloppy API stabilization in object interfaces.
As for changing internals: the same can happen with text-based tools, too. In fact, it has already. I can't tell you how frustrating I find it to deal with the disparities between Solaris tools and the equivalent GNU ones - I prefer the GNU tools because I'm more accustomed to them and I think the changes they provide help to deal with a wider range of problems - but the change from one version of 'find' to another, for instance, requires the use of a different set of command line switches and different text-processing logic as a result. Things change, no matter what underlying technology you use. Stabilizing one's interfaces is a problem that must be solved regardless of whether you're streaming text or passing objects. You could standardize your field-delimiter syntax and still you'd need to stabilize your field order. (Hence,
And while specific object classes may be application-specific, the means to see what they provide is not. As with Python, you can tell what all the methods and attributes of an object are.
As for the separate output step: As I said, I'd prefer a more elegant solution. But here's the thing: along each step of a command chain, you want that data to be easy to process. It's just at the last step that you want it to be easy to read. By using structured data, the intermediate steps are some level of compromise (because - guess w
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Suppose I want to iterate through audio files on the filesystem - get "title" metadata from those that have it, and the length of the audio in time units, format that into a list structure and save it in an environment variable.
If this is all stuff that's part of the file format, this is not a shell programming activity at all. file(1) should be taught about all the fields in /etc/magic and then you can just capture its output and do what you wish with the various fields.
I disagree. file(1) has a very specific task - which is to make a best-guess about a file format based on its contents. If you start expecting it to be actually able to interpret all those file formats - you've got a very large program, now, implementing a lot of functionality that is the proper domain of more specialized tools. No, 'file' should simply be able to tell us what program or library on the system we should talk to if we want to interpret the file. That's where the problem crops up in my example - we have the tools - we can certainly pull out title tags with mp3info - and I expect there are other tools that could do it for other formats. The problem, at a basic level, is that these tools don't even have a common interface. It could be sufficient to say "call mp3info for this file, call sox for this file", etc - but you'd also need to supply the proper calling format and the means to parse the output to get the info you want.
This, I contend, is where an object-oriented interface is useful. You say "I want the title field from this audio file", and the shell
1: Determines the format of the file. I'd like to have that information stored in a file's extended attributes - but files lacking that (files served over NFS or off a CD-ROM, or files on systems where people just don't want a bunch of Xattr's floating around for whatever reason) could provide the information in the file extension (UGH) or using file(1) magic.
2: Find the code that tells the shell how to deal with the file. For an OO shell this would likely be a file format handling library - an interface to pre-existing utility libraries, written to work nicely with the OO shell. This library would need to provide various common interfaces to the files in question (for instance, provide a method to decode compressed audio, or tell the shell that a WAVE file is also a type of RIFF file) and provide more specific interfaces to things like format-specific (or even file-specific) data fields.
3: Call the library, making the specified requests.
The specific advantage this provides over traditional shells is that the OO shell can provide domain-specific help in obtaining the correct result. It would be possible, for instance, to have one command-line program to deal with each distinct audio format, and give them very similar interfaces, but then the script writer must take care to call the correct one for each file. It would be possible to create a master audio tool like "sox", but also give it plugin support and add plugins for all relevant file formats - but this just solves one particular case. Do we do the same for all image formats? All video formats? I think that kind of framework would be a good addition to the shell.
the OO solution would be to ask each file for this information.
I'm neither a fan of OO nor a fan of executable data that may have come off-host, but to each his own. In the case of file types, I am a fan of teaching file(1) about the format and letting it do all the messy work. Do one thing and do it well is ancient Unix wisdom more ignored than followed now-a-days, but this kind of stuff is what that program was designed to do. I do believe it is an utter mistake to judge file types by extensions.
You misunderstand, I think. Your MP3 files are not executable. However, the shell does provide an executable interface to them through format-specific libraries. So you really jus
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Whether the result is good or not is a matter of opinion. As a Unix user I find some of their decisions distasteful, but I can understand their reasons for making the decisions they did. (The verbose command names, for instance, probably help internationalization) - but I think the direction they've gone is a smart one. They've taken the Unix philosophy of small tools that work well in combination, and extended it so it can work sensibly with much larger, more complex datatypes. Managing that level of complexity benefits from using a consistent mechanism to represent non-trivial data structures. You could create a "consistent mechanism" any way you like, of course - define IFF tags for all file types on your system, encode everything in XML - whatever - and you could still pass the data over regular interprocess pipes. However, there are some implications to this. First off, when the data format becomes significantly complex, the "human readable" advantages of text formats vanish. Fields become populated with escape characters to avoid the use of delimiter characters, the mass of data becomes too large to sensibly view with a raw dump, (or, if you're passing binary over the channel, it ceases to be "human readable" through a console dump at all), etc. Second, you're passing much more data than you need to, which can get rather wasteful. A shell that knows how to pass structured data can make intelligent decisions about how to pass that data. I think in Powershell the basic idea is that the shell helps to determine the object's lifetime, but the actual hosting of the object is done through an object manager (think CORBA).
I don't think Powershell provides any means to actually stream data. So the equivalent of "primes | head | tail" wouldn't work quite the same. (Actually, 'primes' would have to be written so as to return an object capable of generating primes, rather than as an endless data stream of primes. The shell expects 'primes' to actually finish running before calling 'head') I think it might be better to have a system where structured data can be streamed, so that programs in the pipeline don't have to wait for all the data, just the pieces they want.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Let me tell you something: it did not work.
Too complicated and confussing, you have to made up all the "common language" and the interface between programming languages becomes more complex than the code for the problem you are actually trying to solve.
Text is easy to parse and backwards compatible, and if you organize it cleverly, it can represent objects (XML!)
IANAL but write like a drunk one.
This is what you didn't want me to do:
find . -wholename '*bath*' -print0 | xargs -0 rm
nor this ('+' is an xargs-like operator to replace ';'):
find . -wholename '*bath*' -exec rm '{}' '+'
grep's -0 operates on output, not input since it's not needed (due to find having the capability already),
two ways to do it with perl doing what grep would normally do but with null on input instead of output:
find . -print0 | perl -0ne 'print if grep {/blah/} $_' | xargs -0 rm
find . -print0 | perl -0pe 'grep {s/.*blah.*//} $_' | xargs -0 rm
Now do it in powershell.
Claiming that powershell doesn't mess up filenames compared to shell is missing the point because the find command is strong enough to support all file name (and file status) manipulation directly. "Please fix this, but don't do it the Unix way" is not a valid challenge. Passing filenames throuh pipes is not typical with the robust find command already, but there are -0-like switches for that just in case.
Explaining WPS to you would be like trying to explain calculus to a cockroach. Except that the cockroach would probably find it mildly interesting.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
The other responder beat me to the answer - but I wanted to sound a further warning, that "xargs" is never the right thing to use in conjunction with find. As noted find has -exec (which you are supposed to use), but beyond just using a tool the way it's meant to be used I have seen limitations with xargs flaking out if a directory tree gets too deep. "-exec" will never run into an issue because it always runs in the directory of the target, and thus does not rely on a ginormous path + file being passed in.
Xargs has other good uses (I'm sure, though I personally almost never use it) but find is not one of them.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Not quite. Text is universal by virtue of it being a stream of bytes, and byte streams are universal in that almost all current computer architectures, networks, storage devices and other devices handle byte streams. In that regard, text isn't just universal in that all programs that you can pipe together in a shell can handle it, but also since you can read it from disk, store it to disk, send/receive it over a network or even send it over an RS232 link, if you so wish.
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.
Well, let me ask you this: why not invent one?
For sure, I understand that people the world over aren't going to embrace a new system like that overnight. But people who use a shell who uses that kind of system would be fine with it. People write modules for Perl, Python, Ruby, etc. all the time - each of those is a scripting language with its own ideas about how to store objects. Do people feel "locked in" by Perl? I'm sure some do - but a lot of people are quite happy with Perl, and the CPAN has all kinds of code (Perl code and binary modules) that are good in nothing but Perl.
Also consider this: once you make a data structure transparent in one way, it is easier to make it accessible in other environments, too. For instance you could say "here's a binary data file. It has a matrix in it" and people would get nowhere - or you could say "here's a binary data file. Its dimensions are (m) by (n), it's stored in column-major format, IEEE double-precision, little endian format, it's not a sparse matrix, and the numeric data starts at offset (x)." - a live object providing that information would make a very convenient starting point for importing the data into Perl, Python, or any other scripting language.
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.
My point is that binary "text" is readable specifically because we've established conventions and provided tools that make it readable. If you do the same for a binary format, the same will be true for that binary format.
You can say that some live objects may not be serializable: that is certainly true. Sometimes they're too ephemeral for that, too specific to current operating informat
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
You can't invent a standard object format because it's only meaningful for a limited set of applications. The rest, well, you can sort and display based on fields, but you can do so with awk. With this, you just need to know the name of the field rather than the number of the column. And that's about it.
General purpose tools now have to convert things to text or create some mapping between generic objects and particular objects. Or you have to implement objects as dictionaries, and just treat the field names as meaningless keys (which they pretty much are).
I'm sorry, I just don't see much use. It's like template metaprogramming: probably useful in some edge cases, but probably not revolutionary for the average user.
That is exactly the problem with the idea.
sort can take input from du, ls, df, or arbitrary scripts, you only need to define the key for sorting and that is it.
If you use objects the output of du is completely different from the output of ls, df or another arbitrary script, ther is no way a predefined sort method could deal with that.
Thsi for sure means that you have to overload the methods to fit the data. So from one flexible, elegant solution we would need to move to a contrived one using obejcts where in reality we don't need them or they become a liability.
The idea is interesting, but gut feeling is telling me that the MS approach of one size fits all may be pervading this.
IANAL but write like a drunk one.
So you will have to come with a better example to get us exited.
Making everything an object may be a solution looking for a problem to solve....
IANAL but write like a drunk one.
Whatever you are using clearly doesn't cut the mustard.
IANAL but write like a drunk one.
Actually, that is PowerShells biggest weakness as a integration shell.
Ok, I know that is a sweeping generalization to grab reader's interest and you do back down from it later on and come away with somewhat sensible argument why PowerShell doesn't suit your specific case. However, your opening statement is a) wrong, b) dangerous and c) totally overrated, that I have to respond even if the discussion has already died.
It is conceptual mistake to claim that a character stream is more generally useful abstraction ("a common lingo") than an object is. If you were to equate character stream and a bitstream then you could convincingly claim a character/bit stream to a lower level abstraction than an object, but I think it would be obvious to all that a raw bit stream is in fact not a very useful abstraction in most real world integration situations. It is however, far from clear are what the relative general merits of an object and a unix-style character stream, which is best understood as a mixture of character data, markup and positional information in integration situations.
In structured programming, objects are the way to go. As you point up this may not be readily applicable to all integration situations. However, if the integrator has fairly good control of the whole environment, they will be in position to ensure that required objects are available. Anyone working within an organization will have that level of control, assuming they are working on an authorized project.
In my mind using PowerShell is very important decision that should be made by people responsible for general IT strategy, however it is also a tool that could make many things a lot easier in a mixed window-*nix environment. Increases in productivity, both form increased efficiency and increased production, could be huge. It is a tool that you will ignore at your own peril. Everybody should be aware of it, if only so that they won't be blindsided by development to come.
Computers are useless. They can only give you answers - Pablo Picasso
You can't invent a standard object format because it's only meaningful for a limited set of applications.
Nonsense. People invent data formats all the time. There's a long path to making something "standard" (whether "de facto" standard or approved by some standards committee) of course, but it can be done. This is how progress works - you have to go out on a limb, try something that may not even work, sometimes something that's so alien to people that they're very resistant to the change. And if it works out, then maybe in a few years it'll start to become popular.
The rest, well, you can sort and display based on fields, but you can do so with awk. With this, you just need to know the name of the field rather than the number of the column. And that's about it.
This is true for very simple data structures. However, this is nevertheless a piece of information about how the data is structured which is not accessible in any way from the data itself. The thing about a "standard object format" is that it doesn't need to mandate how data is stored, just how information about the format of the data is communicated. Bash doesn't tell anyone anything about the format of data that goes between processes. It can't, it doesn't know how. If it wanted to, it'd need cooperation from the programs in question, and it'd need some mutually agreed-upon means of communicating that information.
Let's suppose you had a shell program that did nothing but parse C++ source code for other programs. That's all fine and good, but how does it output the result, such that it's both a complete representation of the source, and an easier form for other tools to work with? Some XML format might be a candidate - though requiring your tools to all handle XML is a fairly steep demand.
General purpose tools now have to convert things to text or create some mapping between generic objects and particular objects. Or you have to implement objects as dictionaries, and just treat the field names as meaningless keys (which they pretty much are).
But in text pipes, you are not just converting data to text at your last step, you're converting back and forth on every step.
/etc/passwd or a crontab, that could be perfectly fine - the file format is so mind-numbingly simple that there's not much to think about. Truly extensible file formats, extremely large files, and so on, are a different matter. What if I wanted to apply the pipelining system to a 2GiB numeric matrix? Or audio data and/or video data that I want to process and encode?
If I'm just grokking
The answer is, of course, that this sort of thing can be done, and in some cases presently is done with traditional pipelines. Behind the scenes, for instance, mkisofs may be piped to cdrecord, or mp3 decoding may be piped to ogg encoding - this stuff is used and does work. I would characterize the advantages of an OO system in this case as follows:
1: Data type checking, and autoconversion: Let's suppose you did something stupid and passed raw MP3 data to a program expecting only uncompressed WAV data. Most likely the receiving program will quickly realize the incoming data is not a RIFF format, let alone a WAV file, and reject it. But there could be cases where this isn't so easy. Suppose you're passing a buffer of numeric values - single precision floats - to a program expecting double-precision floats in a different byte order. There's no way to catch that. But if the sending program can communicate about the format it's providing, and the receiving program can communicate about the kind of data it's expecting, then the shell can act as an intermediary - implementing a consistent set of rules for what to convert and how, when to present the user with a warning or error message, and so on. If you did something really stupid, like sending MP3 data to a program expecting a text file, the request would be rejected. MP3 data isn't t
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Well, that's good to know: the thing is, the versatility of the shell in approaching different problems is of more interest than the specific operations that are made convenient. You've demonstrated that changing the extensions of files is a bad example - because the "ren" command provides a convenient means of doing that. Whether Bash's flexibility is compensation for insufficient specialization for common operations - or whether cmd's specializations are compensation for insufficient power in the command language is kind of debatable, and largely a matter of opinion.
But the power and versatility demonstrated in the Bash example - the ability to evaluate a substitution inline, mainly - I think that was the point of that post. We want to know what the equivalent to that is. There's bound to be some other case where an inline substitution would be handy - a case in which maybe CMD doesn't offer any specialized tool for the job.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
The "repeating pattern" is that as people encounter specific problem domains, they devise tools that are particularly suited to solving the problems. LISP could possibly encapsulate everything everywhere - maybe - but as a language LISP isn't as nice for interactive shell sessions as bash, it's not as efficient for expressing text processing problems as Perl, it's not as well suited to exploring and expressing a wide variety of object concepts as Python, etc.
The problem is, LISP can't nicely encapsulate all these different, domain-specific data formats. That's why domain-specific solutions exist in the first place. But, maybe more to the point, it doesn't. Even if it could, it doesn't. There's a big difference between something being possible and something existing as a readily-available solution. Yes, it's possible that a modern system could be built entirely around LISP. It might not be a bad idea. But unless such a system exists, that's meaningless. So who cares? Either write this environment, and prove its greatness, or else kindly acknowledge that while you think a system revolving all around LISP would be dandy, you have nothing more than idle speculation to base that on.
Did LISP in 1958 unify data transfer between digital audio applications, 3-D mesh editors, bitmap and vector graphics editors, word processors, video codecs, and spreadsheets? Of course not. Maybe things have gone downhill since then - if you prefer to think of it that way - and we're just now starting to reintroduce common communication formats back into computing. Whatever - I wasn't even born in 1958. Object-oriented command shells are, as far as I'm concerned, a nice improvement over command shells I've used in the last fourteen years since I started using PCs, so even if you somehow consider this thing a reinvention of LISP (seems like more than a bit of a stretch to me) it's still progress over the current state of affairs.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Thanks for your comment. Yes, the opening statement is a "flame-ish" punch to get attention. My signature does mention "insightful troll", as a reflection of writing style.
And, I do say that PowerShell can be the best thing since sliced bread where it's appropriate. You are correct in that when all methods are available, PowerShell can be used as a fantastic integration tool.
It still fails in "ad-hoc" usage, except where "ad-hac" means common desktop command line use.
For my purposes (reading others log files, mostly), the Unix paradigm works better. And PowerShell also works here, but only as an implementation of the Unix paradigm. The object nature doesn't help (yet -- maybe log file implementors will introduce an object classification that everyone can agree with).
Have a GREAT weekend!
Just another "Cubible(sic) Joe" 2 17 3061
Access the gui? Why, did somebody strand a bunch of functionality in "the gui" where scripts can't access it?
Nah, nobody would ever be that stupid.
Yet handling these steps seems more practical than trying to share data format definitions between languages.
Every language that takes part in a Unix pipeline has to handle text -- awkward, but doable.
Every language that takes part in the object pipeline you describe has to have a shared way of defining structured binary data -- historically, a huge tangled problem that has probably spawned more short-lived and nonstandard "standards" than any other kind of computing problem. These "standards," despite being intended to enable compatibility, have caused more incompatibilities than any other kind of computing technology.
In this case, text is the best solution, perhaps because it isn't a solution at all.
Access the gui? Why, did somebody strand a bunch of functionality in "the gui" where scripts can't access it?
Nah, nobody would ever be that stupid.
Heh. Actually, I think almost everybody was "that stupid".
MacOS started out as a system that was built from the ground-up with the assumptions of their GUI (hence, filesystem supporting things like forks and resources and a formal notion of type IDs for files) - it has since switched to a more hybrid approach - retaining some of that (including the HFS filesystem) but mostly for backward compatibility - new Mac stuff is designed for lesser assumptions about the filesystem so that the OS will work on HFS but also play nice with other filesystems.
Windows doesn't really have a distinct notion of what defines the "GUI environment" and what defines the "Command-line environment" - the whole system is built around the assumption that the GUI is running on a display somewhere. The underpinnings are reasonably modern and getting better - though filename extensions are still used to infer types, and if you were to consider Windows versions of bash or cmd.exe to be the "Windows command-line environment" then the separation in terms of concepts and functionality is pretty severe. But then you've got powershell, of course, which is like a somewhat Unix-ish shell (mainly in the general concepts of the prompt, the PATH, the filesystem, and command structures like piping) but deeply rooted in Windows technology and style - perhaps the system with the least "split personality disorder" between the text interface and the graphical one, surprisingly.
And then there's Linux. The GUI is being built up as a sort of mimicry of Mac and Windows, with a few old-school X-isms thrown in for good measure - Gnome and KDE each include their respective scripting interfaces (ORBit and dcop, currently) but the components that make up Gnome or KDE are often considered separate from the system - people still write X apps that aren't integrated into or compliant with either environment, and I think many people don't like to incur those dependencies for fear of over-complicating their program or limiting it to just the people who use that particular environment to begin with - so neither system is treated like an assumption, it's strictly an add-on and largely self-contained within its community. Straight X apps and console apps tend to make very few assumptions beyond the POSIX-like system call environment and filesystem, the standard C library, and the terminal or X server. Few projects outside of GNOME or KDE projects assume the presence of an object broker or any particular RPC or IPC mechanism, let alone the more advanced concepts these frameworks implement, such as scriptable application interfaces, data exchange, and so on.
Put simply, it's my contention that on Linux, the GUI frameworks are creating an environment which, from the point of view of the command shell, is fiction - an elaborate facade built on top of machinery that is adequate for the task, but not well tailored to it. What I advocate is not necessarily that these technologies be embraced to create a more specialized shell environment (after all, the changes in Gnome and KDE are a little unsettling if it's stability you're after - KDE dumping CORBA in favor of their dcop system - Gnome possibly dumping CORBA in favor of Mono in the future - apart from the fact that people often don't want these technologies to be a part of the basic assumptions on their system, the technologies simply haven't settled to the point that this is practical...) - but rather a shell environment with sufficient powers of expression and representation to be able to interact well with these technologies. What's missing is the ability for the shell to host and exchange "objects" (meaning, pieces of data - not even necessarily in an OO sense) that have specific requirements for managing their "lifetime" (code to be called when the data is copied or deleted, for instance) Beyond that, wha
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
Dude, you totally rock. I love your response. It's a perfect criticism and I love the delivery - with just a hint of sarcasm at the end to drive the point home. It's a pity you posted anonymously - but I don't hold that against you.
The person I was replying to suggested that there was no "universally agreed syntax for objects" - which is true. The point I was trying to make (and not making well) was that such a format doesn't need to be "universally agreed" upon, standardized, or pre-existing. If we want progress and have a good idea of what form we want that progress to take, we can build new systems as necessary.
As for creating a new format - if none of the existing ones are really suitable it's the way to go. The plan for the format is based on three key features. First is the ability to wrap established data types for identification. Second is the provision of an adequate set of data types (numbers, text, lists, tables, structures, and objects) to allow information to be expressed in a generic manner. Third is versatile streaming order of data, to allow more versatile pipelines. A metaformat that provides significantly more than that is overkill. A specific format that provides less than that is inadequate.
As for my assertion that no existing formats meet my needs - well, it's an assumption, really. I'm trying to be sure that it's the right conclusion. This means research. But defining a new and compact format that I know is well-suited to what I'm trying to do may be more productive than hunting for one that might be well-suited to what I'm trying to do.
It's quite possible that I could accomplish what I want in some binary encoding of XML - or, rather, use the assumption of an XML encoding as the outermost "layer" of the data as a way to reliably communicate the fact that the contents are in this new format I want to produce - that would have the advantage of playing nicely with all the code out there that looks for XML, at least. It's sort of like going to China knowing no phrases in Mandarin or Cantonese other than "the rest of what I am about to say is in Esperanto." - but that is the whole idea here - tell whoever's listening what language the speaker is speaking - whether that language is PDF, XML, MP3, whatever. I'm not sure if I would want to go that specific route, however.
---GEC
I'm but the humble pupil, seeking to snatch the scratchbuilt pebble from the master's fully articulated hand
irb, IDLE, beanshell...