Slashdot Mirror
Windows PowerShell in Action
jlcopeland writes "For two decades I've hated the command prompt in DOS and Windows.
Inconsistencies abound and everything is a special case. The
fallback on a Microsoft box has been running a Unix shell under Cygwin or
installing Microsoft's
own Services for Unix (or its predecessor, Softway's Interix),
or by scripting in Perl, but those only get
you so far. Having co-written nine years worth of trade rag columns
using mostly Perl as the implementation language for the samples,
and thinking of every problem that comes across
my desk as an excuse to write a little bit of scripting code,
I've got some well-formed views about scripting languages
and what works and what doesn't. That means
I've been eagerly watching the development of PowerShell since it
was called Monad. It's got the advantage of being a unified command-line
interface and scripting language for Windows, even if it does have
a dorky name." Read the rest of Jeffrey's review.
Windows PowerShell in Action
author
Bruce Payette
pages
576
publisher
Manning
rating
9
reviewer
Jeffrey Copeland
ISBN
1932394907
summary
Guide to PowerShell, the new Windows scripting language
Bruce Payette's Windows PowerShell in Action is a great overview of PowerShell, aimed at an audience that's got some experience with other scripting languages. Bruce's book is a big improvement over Andy Oakley's earlier book, Monad, which I had been using: it's more complete and it's up-to-date for the first release of PowerShell. It's got great (and sometimes amusing) examples, and feels like the Perl Camel book in flow. When I was reading it in the gym or someplace else away from the keyboard, I kept wanting to run back to the office to try something out. There are also useful "why it works this way" digressions, which provide a lot of context. Since Bruce was on the original development team, wrote most of the commandlets, and was responsible for much of the language design, those digressions are more authoratitive than the directors' commentary tracks on most DVDs.
In outline, the nine chapters in the first part of the book build up as you'd expect: overview and concepts, to data types, to operators, to regular expressions, to syntax, to functions, to interpreting errors. It covers that ground better than many language books that now litter my shelves. The explanations are clear, and the examples are almost all exactly on point. It took me a second reading to realize that my complaints about the regular expression sub-chapter wasn't about the chapter itself, but about some of the implementation decisions; that's an argument about style more than substance, and an observation about me, not about Bruce's writing or PowerShell. The first part of the book is the "mandatory reading," if you will, to get the language down and begin exploring on your own.
The second part is where the real applications are covered. That's the part that you especially want to read sitting next to the keyboard. As you'd expect, the example code is available from the publisher's web site to start you off — look for "Example Code" under "Resources." There's a very good discussion of text processing and how-to-handle XML, complete with some not-obvious warnings about traps to avoid. I've been working very carefully through the really good chapter on using GUIs with PowerShell, "Getting Fancy — .NET and WinForms," and my own proof of concept for that has been rebuilding an old C++ data entry application into a much simpler PowerShell script. As a nice side effect, Bruce's book (and the WinForms chapter in particular) provide a gentle overview to some concepts in the .NET framework, which I hadn't had an opportunity to delve into. The appendix on using PowerShell as a management application will be especially useful to system managers; that was one of the original PoweShell target audiences, and the language achieved that goal very well. The appendix on the language's grammar is really useful, and I keep flipping back to it to check on things.
After Oakley's Monad appeared, there was a long gap before the next PowerShell book appeared. Bruce's book looks to be the first of the post-release wave. If all it had going for it was the authoratative pedigree of the writer, it might be worth it, but it's also well-written, well-organized, and thorough, which I think makes it invaluable as both a learning tool and a reference.
You can purchase Windows PowerShell in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Bruce Payette's Windows PowerShell in Action is a great overview of PowerShell, aimed at an audience that's got some experience with other scripting languages. Bruce's book is a big improvement over Andy Oakley's earlier book, Monad, which I had been using: it's more complete and it's up-to-date for the first release of PowerShell. It's got great (and sometimes amusing) examples, and feels like the Perl Camel book in flow. When I was reading it in the gym or someplace else away from the keyboard, I kept wanting to run back to the office to try something out. There are also useful "why it works this way" digressions, which provide a lot of context. Since Bruce was on the original development team, wrote most of the commandlets, and was responsible for much of the language design, those digressions are more authoratitive than the directors' commentary tracks on most DVDs.
In outline, the nine chapters in the first part of the book build up as you'd expect: overview and concepts, to data types, to operators, to regular expressions, to syntax, to functions, to interpreting errors. It covers that ground better than many language books that now litter my shelves. The explanations are clear, and the examples are almost all exactly on point. It took me a second reading to realize that my complaints about the regular expression sub-chapter wasn't about the chapter itself, but about some of the implementation decisions; that's an argument about style more than substance, and an observation about me, not about Bruce's writing or PowerShell. The first part of the book is the "mandatory reading," if you will, to get the language down and begin exploring on your own.
The second part is where the real applications are covered. That's the part that you especially want to read sitting next to the keyboard. As you'd expect, the example code is available from the publisher's web site to start you off — look for "Example Code" under "Resources." There's a very good discussion of text processing and how-to-handle XML, complete with some not-obvious warnings about traps to avoid. I've been working very carefully through the really good chapter on using GUIs with PowerShell, "Getting Fancy — .NET and WinForms," and my own proof of concept for that has been rebuilding an old C++ data entry application into a much simpler PowerShell script. As a nice side effect, Bruce's book (and the WinForms chapter in particular) provide a gentle overview to some concepts in the .NET framework, which I hadn't had an opportunity to delve into. The appendix on using PowerShell as a management application will be especially useful to system managers; that was one of the original PoweShell target audiences, and the language achieved that goal very well. The appendix on the language's grammar is really useful, and I keep flipping back to it to check on things.
After Oakley's Monad appeared, there was a long gap before the next PowerShell book appeared. Bruce's book looks to be the first of the post-release wave. If all it had going for it was the authoratative pedigree of the writer, it might be worth it, but it's also well-written, well-organized, and thorough, which I think makes it invaluable as both a learning tool and a reference.
You can purchase Windows PowerShell in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Named after the designer lost a testicle in a tragic chair throwing accident.
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
is one of the nicest things that came out of Redmond. Ever. My only complain is that it is tight integrated to .NET, but OTOH I believe this is necesary to integrate the always nice C# to it, which is of course a plus.... You can't have the cake and eat it...
It's time to realise that Abble's products are the biggest abomination these days. Just say NO to the dumb iAbble way!!
...in 20 years MS will invent UNIX.
Powershell is very powerful. Much more so than cmd.exe. I don't have significant enough experience with bash to compare the two but I would not be surprised to learn Powershell equals if not beats bash at the shell game. I wouldn't say it is ready to replace any of the scripting languages just yet.
I have been using it for a while now and the single (semi-major) problem I can find is memory usage. It is a hog at best, and at worst when you are using it semi-heavily it can easily chew up 1GB of memory. That's even with giving the GC something to work with, ie unsetting $vars when you are done with their data.
I wish they'd kept "monad" as the name. It was a deft tip of the hat to Leibniz's Monadologie, which held that monads were the windowless metaphysical atoms of perception itself.
Inconsistencies abound and everything is a special case.
You should switch to bash and the GNU tools.
Oh, wait.
Proud member of the Weirdo-American community.
Image Magick tools run fine under windows in a pinch.
Autonomous Retard -- Is your camp safe? UnsafeCamp.com
Now all we need is for Sun to develop a Solaris-only shell, Apple to develop a Mac-only shell, and RedHat to develop a Linux-only shell. I hate re-using code because it forces me to solve new problems every day. I'd rather create new value on Mondays only, and then spend the rest of the week re-doing the same work on my other platforms. It gives my mind a chance to rest, and I can drink heavily mid-week and still be able to do my job.
I sure hope they charge extra for it, make it a resource hog, lock out third-pary extensions, and then discontinue it as soon as I'm dependant on it. I really liked the 1980s and look forward to reliving them.
2017, the year of the linux desktop!
YOu do realize that 90% of users have aboslutely no need for a shell, right? I would argue most power users don't need a shell.
Just remember - if the world didn't suck, we would all fall off.
I don't use Monad (:s/M/G/g) or intend to, so I don't care much about the book. But what a great review. We get a lot of amateur reviews around here, but this one was particularly well written, clear, and informative. Nice job, homie.
If this were Usenet, I'd killfile the lot of you.
Are we talking desktop or server here? In the server world, it's a different picture, and it's quite true that Microsoft has never had a command scripting language that was half as easy to use and as versatile as Bourne shell and its descendants. You can do a lot with NT batch scripting, but it's a tedious and horrid creature that leaves you with frequently incomprehensible scripts. It's nice to see that MS has recognized that, and finally recognized that good command line tools are an important part of a system administrator's bag of tricks. I cannot count the number of times I've wished for something like Bash that was integrated into Windows. Yes, you can use VBScript or JScript, but what little there is for file support is just plain hideous, and trying to work with standard input and output is just too clumsy to be really workable.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Doesn't work in XP.
All my scripts that worked in Win2000 and 98 fail to work. Granted the image manipulation parts work but putting copies in different directories don't work.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
What is wrong with Cygwin? How can he bash Cygwin (sorry, no pun intended) without even bothering to say anything about it?
There was no competing OS when IBM chose to push it (DOS).
Windows got it's push from 3rd party money (IBM and others) thus adding to it's war chest.
Linux doesn't have the resources that Microsoft had to get it polished to the current level.
if you steal from one source, that is plagiarism, if you steal from many, well, that's just research.
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!
Well, if you count the number of licenses sold, Linux will _NEVER_ have 20% of the market. What I'm seeing of home users and hearing from people I know, Linux has about 10% or so, and is growing. The cost of Vista and the upgrade pains coupled with the inevitable payment for help they will need is starting to crumble the veil of superiority that Windows has held for so long.
Yes, that sounds roughly fanboi-ish, but it's a reflection of what I see in the world around me, not what I imagine. I recently handed Ubuntu CDs to two barmaids that were fed up with trying to get Windows for free as they can't afford the cost of a legal copy. They are not technically minded, they installed it themselves and are now very happy and not going back. A decision they made shortly after I gave them advice on what tweaks to make to Firefox... I see this being repeated all the time yet these people will not be counted in the desktop market share wars.
Support NYCountryLawyer RIAA vs People
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?
I did quite a bit of work with Cygwin a few years ago, even managing to get FreeRadius up and running. It's good from the limited perspective of needing a *nix tool and having an environment to do it in, but Cygwin is really kludgy, to the point that I finally gave up on it. I just don't think it's stable or efficient enough to be trusted with production tasks. It's great for "gee-wiz, I'm running KDE in my Windoze box", but I sure the hell wouldn't want to do anything serious with it.
The world's burning. Moped Jesus spotted on I50. Details at 11.
You forgot MKS toolkit which has most if not all of the standard UNIX utilities along with vi, bash, ksh, sh, awk, sed, etc. What more could you want?
Wrong. 90% of users don't need the old windows/msdos shell. If people had a shell that was as good as bash, then they would use it. As it is now, using the shell in windows doesn't provide any benefit, so nobody bothers to use it. You can't say people don't need a shell when they don't have one. It's like saying people didn't need macros in word processors before the existed. Nobody used macros because the option wasn't available to them. Now that macros are available, many people do use them, and not just the power users. MS assumes that everybody is an idiot, and therefore doesn't provide tools that people with the right skills would actually use. Therefore, nobody has the opportunity to develop skills with these tools. Take a look at some of the stuff in XP, like that search dog, and the dumbed-down control panel and management options. With features like that it's no wonder people don't learn anything about computers, when the computer assumes they don't.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Every time I use Linux, I find it amazing that people still use Open Source software. It's pretty good, but it seems to be missing a lot of key features. Things like 3D acceleration are decades behind Windows. I can't even play Half-Life at all.
People use Windows because most people are not looking for the same things in an OS that you are. I know it's an easy way to get some karma here on Slashdot, but saying you can't believe anyone uses Windows because the shell sucks and you've had bad experiences resizing pictures is absurd.
correct, there was already vbscript which can do everything and then some (even if the learning curve is akin to ripping off your eyelids...) while i haven't used powershell yet, i have not had a need to use it. the switch to powershell will eventually be made since longhorn server will include it. it should begin the end of the vbscript era..
1998 was the year of the linux desktop, at least for me it was. And I was a die hard Windows/Dos user before that. I had only passing exposure to Unix. December 10th 1998 my windows 95 died. I decided to install Linux Redhat 5.0 and never looked back. Unfortunately I am now stuck on a Mac.
What is the meaning of this "The year of the Linux Desktop?"
Paying taxes to buy civilization is like paying a hooker to buy love.
I would argue most power users don't need a shell.
.NET String object has an API that's a lot easier than sed and awk.
:-)
I'd say that power users who think they don't need a shell don't know what they're missing ; they could have a lot more power.
The gentleman sitting next to me has recently discovered and raves about WinGrep, a GUI file search/replace utility with RegExp support. It's not bad, but it can't compare with a shell - you can't, for instance, search for a bunch of files containing your desired pattern match and invoke an external utility to process each one. And anything that the original application designer didn't visualise as a feature is excluded. He's easily capable of comprehending grep and sed, which would do the same job for free, but he's more comfortable with the GUI.
In a *nix style shell, the ability to pipeline STDOUT through a whole bunch of little utils is the tool of a real power user - and it has a nice easy learning curve, you can pick up new commands as and when you like, and combine them with old favourites. The downside to the *nix shell is that very often you have to perform some esoteric text processing to get what you want, which means learning tools like awk and sed. Powershell works by passing objects through the pipeline - objects that have useful properties. It's even an improvement with old-style executables that emit pure text - the
The GUI equivalent of a shell for a power user would be a pipeline composer where you can take various widgets representing actions and plug them together. Perhaps something like the DTS transform designer in SQL Enterprise Manager. Or maybe not
Have you tried the suite of utils that David Korn wrote for Windows? Just curious. I tried it several years ago, and was impressed. I haven't done a side-by-side between Cygwin and Korn's tools, though.
Method of processing duck feet
harry@satan:~$ apt-cache search powershell
powershell - powerful terminal emulator for GNOME
Saying you don't need a shell just means you have found clunky, typically inefficient workarounds, or you are just living without its benefits.
Sure you can live without a vacuum cleaner, but your carpet and overall cleanliness is going to suffer for it. I know people who live in apartments without vacuum cleaners and they are very similar to computers who's users don't use or understand shells.
Paying taxes to buy civilization is like paying a hooker to buy love.
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.
Most people may not need a command-line shell, and power users may survive without one, but that doesn't mean it isn't a valuable part of a toolkit.
In particular, a good command-line interface (such as those found in many unix variants) is much more flexible than any GUI I've seen so far. Its strength comes from the ability to combine several simple tools together to build up a more complex and powerful one. I often reach for the command-line when I want to do something to a number of different files, for example mass renaming, adding ReplayGain tags to audio files, or any number of other such things. Of course any one of these things can be done through a GUI, but the point to notice is that the command-line shell needn't be specifically designed for any such task -- it offers the possibility not through a specific feature implemented explicitly for that task but by offering a flexible collection of tools to be freely used and combined. Usually GUIs will do mostly just those things they were designed for.
Of course, the things I use the command-line for could probably be done with a GUI even without a specific feature for the task, but it might well mean more manual work -- and power users don't like that.
When you're putting together a good, *free* mail server or file sharing server, 3D acceleration doesn't count. It's the kind of guys putting together servers who are in the most need of good shells. The *nix shells, with chained pipes, just kicks the shit out of Microsoft's languages thus far. Some of the tools are a bit tough to learn (sed is a real nightmare, so I use awk), but I've done some pretty amazing things in bash, massaging nine or ten thousand item catalogs from some distributor's bizarre mainframe format into CSV files with a few lines of awk code. That's the kind of shell and shell tools that are needed; quick-and-dirty tools that don't try to do every goddamn thing possible, but rather do one thing and do it very well.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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.
What I'm saying is that for power users, Windows sucks because it doesn't provide any features geared towards them. I'm also saying that for non-power users it sucks, because you can't just put an image on your desktop, and have it resize to fit the screen automatically. You have to open it up in an image editor, resize it to your desktop, then put it on your desktop. I don't see what any particular person likes about windows, power user or not.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
This is one of the few times i can say, i honestly don't know if you're trolling or not, and i don't mean that in any way an insult. Maybe it's a statement to your relative subtlety
People like things simple, but many things are complex. OS adoption is determined by many factors, technical excellence just being one of them. Consider something "simple" as price?
I could got on for a paragraph or two just on price alone. Early adoption is done by people who have a whole different class of requirements than the mass market. The fact that Linux is going into the mass market at all is a testament to its usefulness.
Things like 3D acceleration are decades behind Windows.
Actually, 3D acceleration in Linux is technologically ahead of Windows. What's behind is driver support, although that's coming around.
People use Windows because most people are not looking for the same things in an OS that you are.
Well, nobody in my family uses Windows anymore: they have all switched to either Mac OS or Ubuntu, both of which are considerably less hassle and overall cheaper.
For those who haven never seen Monad in action and are quick to bash (ha! get it?) Microsoft's new shell, take a look at these two videos. You'll see that it's much more than just bash on Win32. In fact, if it ever catches on, it'll be Unix's turn to play catch-up, because some parts of it are pretty damn amazing. (Note that those are from 2005, but AFAIK, there haven't been substantial changes.)
:-)
The whole point of Monad is that it's not just text, it's objects. So, unlike Unix, where you work with a command and then filter its output (which is just text), the output of Monad, while looking like text, is actually kind of like pointers back to the real thing, so instead of just doing a Unix-style command | filter | filter, you can say "OK, run this command, now of the things it output, go back and tell me this and this about them." Like, "Of these things that are running, tell me which five are using the most CPU time, then tell me the version of each, and how much memory they're using."
PS: "...even if it does have a dorky name"--which name were you referring to: the one that sounds like 'testicle' or the one that makes me think of the Lottery?
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Its the typical .NET deal. First time you run something it takes a bit, after that its instant.
So basically, what makes it suck less, is to use it more.
I have to manage a Windows domain of a 1000+ users and Powershell (yes crap name) allows me to do stuff that you used to only easily do with expensive third party stuff quickly in a few lines. .Net, WMI etc. and it beats Active Directory administration through a GUI any day.
The only other choice to do something similar on Windows is VB script which I find painful at best. It may not be the best Shell ever but at the moment its the best Windows integrated shell with access to
The book is great by the way, and his blog has loads of useful tips too.
Anybody who is actually going to try it, will find the powershell community extension very useful. G
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.
Actually, PowerShell is pretty damn good. I would say it is ahead of bash, not behind. I'm hoping somebody will steal all the good ideas and turn it into a good shell for linux.
/tmp/lsa /tmp/lsb /tmp/lsa & /tmp/lsb & /tmp/ls{a,b}
Examples: Bash is pretty poor where your commands take more than one file and, to a lesser extent, where they produce more than one file.
For instance if you have two directories a and b and want to do a diff on their contents, what do you do:
% mkfifo
% mkfifo
% ls a >
% ls b >
% diff
That's just disgusting.
And control of GUI applications - KDE is a quite nice scripting langauge but it isn't a shell. Bash has virtually no gui scripting and I'd call its tie in with KDE's scripting poor - only the most basic datatypes can be exchanged.
Compare to applescript for an example of a fairly powerful modern scripting system.
Imagine, a whole post on the deficency of the unix shells and I didn't even mention my pet hate of escaping!
I hope this is not a dupe - I certainly was not aware....
l ogies/management/powershell/download.mspx
...PowerShell is avlaibel for MS OS's older than Vista too:
http://www.microsoft.com/windowsserver2003/techno
That's not an apples-to-apples comparison, though.
In cmd.exe, "dir" is "dir." It gives you a text listing of the files and subdirectories of your current directory. In PowerShell, "dir" is an alias for "get-childitem," which returns an object array that can either be parsed for display in the console, or passed down the pipeline to another commandlet.
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.
Just the other day I was using my 3D accelerated Beryl desktop, and playing Half-Life 2, and World of Warcraft in Linux, so remind me again what's decades behind? Incidently, Beryl is much better than Aero, I've seen and used both, and Beryl, if you're shopping for eye candy, is more functional, looks and behaves cooler, and is much lighter on the resource usage than Aero, but then again, it doesn't have to poll all your hardware and spy on your processes constantly to make sure you're not doing anything Microsoft isn't happy about.
Curiosity was framed, Ignorance killed the cat.
in the specific case of diffing the contents of two directories, it's just
$> diff --brief a/ b/
It just seemed worth pointing out.
Can the prompt be the present time ... like my bash prompt?
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.
Just the other day I was using my 3D accelerated Beryl desktop, and playing Half-Life 2, and World of Warcraft in Linux, so remind me again what's decades behind?
Unfortunately, the last time I tried it, Half-Life 2 sucked under Linux - particularly when you got underwater and the framerate became like a slideshow. That has very little to do with Linux's 3D support and a lot more to do with Wine's DirectX support, though. (Besides, who knows, they might've fixed it by now...)
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
Cool! I'm certainly going to start using that :)
" If both from-file and to-file are directories, diff compares corre-
sponding files in both directories, in alphabetical order; this compar-
ison is not recursive unless the -r or --recursive option is given.
diff never compares the actual contents of a directory as if it were a
file. The file that is fully specified may not be standard input,
because standard input is nameless and the notion of ''file with the
same name'' does not apply.
"
Amazing - I've been using diff for hmm, over a decade now, and I don't remember the last time I read the man page...
Like I noticed a couple weeks ago that, since the last time I've read its man page, rsync has added a 'search for similar files with similar but different names option.
90% of users don't need the old windows/msdos shell. If people had a shell that was as good as bash, then they would use it. As it is now, using the shell in windows doesn't provide any benefit, so nobody bothers to use it.
Oh 90%! Just like those 90% of statistics that are made up on the spot. What a coincidence.
- A heavy windows shell user
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
Because so many commercial apps are Windows-only, duh.
Any more stupid questions?
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.
-]Phreak Out[-
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
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."
The questoin is not whether an OS feature is used by users.
The question is does the existence of a feature make an operating system more useful.
There is no question that scripting makes Windows more useful. The problem is that Windows scripting is so bad that its contribution to Windows utility is artificially limited when compared to Unix, and especially MacOS.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
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
Dunno. It could also be "Moan Ad" or "Mo' nad".
We are the 198 proof..
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
OS X's Automator does exactly this...
IBM tried to kill Windows so people would use OS/2. Microsoft took a huge risk by taking on IBM. I've tried using Linux for years, and it's still a terrible user experience. Any modification of your hardware is horrible. Windows usually picks up the change and just works. Linux is much better than it used to be, but it still can't compare to the setup experience of Windows.
yep, and there is a port of lisp to be a shell in unix too but it doesn't quite work as a shell replacement.
Could you imagine using smalltalk as your shell?
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
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
Yea, stupid VPN for work is set to only allow Windows and OSX. No actual technical reason a declaration of "This is what we support" Been on it now for almost a year.
Paying taxes to buy civilization is like paying a hooker to buy love.
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.
Sorry, but Linux does _not_ have 10% of the desktop market -- not even close. I know a lot of people who "use" Linux. Meaning that they installed a random distribution on their computer a long time ago, figured out how to get GRUB to default to the Windows entry, and then promptly forgot about the Linux installation that they couldn't get working properly.
I'm sure that a lot of computers have Linux installed on them, but I'd be surprised if even 5% of desktop users use Linux on a day to day basis. There are quite a few people using Linux casually, like the barmaids you described or my roommate's family, but who happened to run into some nerd who could install it for them (or convince them to install it themselves), but by far most of the users are still geeks. And since most of the geeks who "use" Linux don't actually use it enough to be considered Linux users (not in my mind, anyway), I'm still convinced that only a very small minority of computer users run Linux.
#include ".signature"
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.
Examples: Bash is pretty poor where your commands take more than one file and, to a lesser extent, where they produce more than one file. For instance if you have two directories a and b and want to do a diff on their contents, what do you do: /tmp/lsa /tmp/lsb /tmp/lsa & /tmp/lsb & /tmp/ls{a,b}
% mkfifo
% mkfifo
% ls a >
% ls b >
% diff
That's just disgusting.
Yes that is disgusting. Fortunately, you're not the first person to notice this. Try this instead:
diff <(ls a) <(ls b)
There is a similar syntax for outputs as well. It's not perfect: you can't easily generate a general directed graph, but in that case, you would probably get deadlocks anyway, since programs tend to read files in order.
SJW n. One who posts facts.
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
Try this:
1. Install and use Windows XP for a while.
2. Image the drive into a VM.
3. Boot up VM.
4. ??? (Cannot run, please activate this copy of Windows)
5. Install Ubuntu.
Seriously, nothing concentrates the mind like the threat of being able to access your applications and data after a HD crash.
Even Apple *get* this. I imaged my Mac Mini with all my data onto my iMac. Worked great. Nothing like the security of having a backup image ready to go in the event of a HD crash.
-- "It's not stalking if you're married!" My Wife.
MS PowerShell is a separate download for XP, Vista, and Win2K3. It's not included out of the box in any of them. The point of this shell is that it's object oriented. The classic windows shell and most of the others out there (eg bash) aren't. I'd suggest you pay even a tiny bit of attention to what you're reading but you clearly don't seem to care.
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.
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?
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.
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 had to help a friend with a cmd routine on XP to help him rename and resize a very large number of images, in the end I had to go beyond MS and use mtr ( minitrue)combined with irfanview cmd line. dir /b | mtr -o -x+ - (.*)(Picture" ")(.*)\r = 'ren "\1\2\3" "%num%\3"\r>run.cmd
dir /b | mtr -o -x+ - (.*)(DSCF*)(.*)\r = 'ren "\1\2\3" "%num%\3"\r>>run.cmd
call run.cmd
del run.cmd
i_view32.exe %dest%*.jpg /resize=(%PictWidth%,%PictHeight%) /aspectratio /DPI=(%ThumbDPI%,%DPI2%) /jpgq=%PhotoQuality% /convert="%big%$N.jpg"
i_view32.exe /killmesoftly
i_view32.exe %dest%*.jpg /resize=(%ThumbWidth%,%ThumbHeight%) /aspectratio /DPI=(%ThumbDPI%,%ThumbDPI2%) /jpgq=%ThumbQuality% /convert="%thumb%$N.jpg
i_view32.exe /killmesoftly
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.
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?
That's why I love PHP, print_r('$whatever');
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
what's the point of the named pipes?
aren't those mkfifo's redundant since your lsa and lsb will be created in CWD and not in dir a/ or dir b/?
i just don't get the point but i do admit i really don't use named pipes that often so i have no clue about when, how or why one would use them
> 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.
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
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. From my perspective, the limit is in the extent to which the shell works to support data exchange between programs.
Why does the shell need to support data exchange between programs? Well, that's the whole idea between Unix pipes. Bash supports text streams (or rather, byte streams commonly assumed to be textual) between processes, and that's it. And that could be enough - given a universally respected set of conventions on how to format and identify datatypes. So if ActivePerl gets some nice chunk of data out of a running GUI application, and at bash you're trying to pipe that data output into something else - there's a rather cumbersome process of turning that Perl data into a raw bytestream and turning it back into useful data again. The complexity of this problem depends on the complexity of the data - and bash's willful ignorance of the significance of the data that goes between processes means that it can't help in any way.
What's specifically missing is shell-level support for interacting with GUI applications at the same level that ActivePerl is capable of. Bash's support for datatypes isn't sufficient to make it a good way to interface with scriptable applications.
A statement like "but those only get you so far" is a bit vauge - but I think I can see the point.
---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
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