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!
has microsoft submitted to linux and unix? we have had a "power shell" for a few decades now..
is one of the nicest things that came out of Redmond. Ever. My only complain is that it is tight integrated to .NET, but OTOH I believe this is necesary to integrate the always nice C# to it, which is of course a plus.... You can't have the cake and eat it...
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
...in 20 years MS will invent UNIX.
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.
Having co-written nine years worth of trade rag columns using mostly Perl
Nine years and you haven't learned to move on from Satan's curse. Seriously, linguists shouldn't be allowed to create programming languages. They really don't know what they are doing in this domain. Witness the glacial development of Perl6.
I am becoming gerund, destroyer of verbs.
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.
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.
This patch will do it.
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 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? Yeah, try this critical patch
Thank God for evolution.
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
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
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
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
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
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.
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.
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.
"Those who fail to learn the lessons of Unix are doomed to re-invent it. Poorly." -- Forgot who said it.
Somebody in marketing?
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
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.
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.
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
tracert slashdot.org | clip
:(
Too bad if it's something already on your screen that won't help
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');
> 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.
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
"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.
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
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
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
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.
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...