Slashdot Mirror
Microsoft PowerShell RC1
rst+ack writes "Microsoft has released RC1 version of PowerShell the .NET-based shell with perl-like syntax previously known as Monad or MSH. PowerShell (PS) has been covered a few times on Slashdot. Contrary to cmd.exe and Unix/Linux shells it operates on objects, not text when passing data between scripts and executables. Easy access to .NET classes allows users to create quite advanced solutions in short time. PS won't be shipped with Vista or Windows Server 2007 but it will debut with Exchange 12."
Ahem:
Those who do not understand Unix are condemned to reinvent it, poorly.
Well ... to take the position of "Devil's Advocate" for a minute, if they just extended bash to have C# scripting, then you'd have lots of people on this forum yelling how they are perverting the standard and that this is just aploy for them to embrace and extend the existing shell language.
.Net
.Net bindings for Perl, that may be an even better choice for a scripting language.
Look at it from MS's perspective:
1) They know they need a shell like language to handle sys admin type functions.
2) They've just put a lot of effort into
3) Most of the MS Admins out there believe VB is the tool of choice.
Given those suppositions (feel free to argue about their reality, but remember that I'm discussing it from MS's viewpoint), a scripting language that fullfills (1), takes advantage of (2) and leverages (3) seems like a no brainer, even for them.
Of course, considering that there are
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
So: You want a shell-like environment that lets you type in commands to operate on objects representing files, directories, etc.
Great! Install python*, install the file packages, open the interactive interpreter... you're done.
Why bother waiting for this MONAD thing? It looks like all MONAD offers over any other interactively interpreted programming language right now is that it is compatible with the C# object model. Which, y'know, on the one hand, the UNIX "glue" platforms (python, perl, ruby, kde, gtk) could totally benefit from a unified object model that would allow you to construct an object in a GTK+ application, pass it to a perl script, pipe it to a ruby app, etc. But, y'know, on the other hand, python on windows supports the CLR/C# object model as well... and it's available now.
* Or ruby.
"My problem is how blatantly incompatible they do everything."
And his point was that, within the Windows environment, they ARE compatible, staying with their existing libraries, tools, and languages. Given that perspective, importing yet another language and toolset from Unix would be the incompatibility.
Why does the entire world have to look like a scripting language from an OS designed four decades ago?
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Uh, it is a COMMAND SHELL? Of course it's text input based. They also claim that future graphical admin tools will render the equivalent commands in a text field, somewhat like what you describe. But this one certainly uses a text-based interface... The object-orientation is just about how commands interact with each other, especially when piping. Plain text piping between commands (note, not processes, the builtin commands are objects that will generally live in the same process as the shell itself) is a limited special case of this.
Prepare yourself, this may come as a shock...It supports text based communication. Amongst the vast array of .NET objects is the ever popular System.String, which is of course an object representing plain text. Pipe it to a program and guess what happens? That's right, the .NET part is stripped away and the plain old text is sent to the app.
Microsoft gets it just fine. They get that *nix's text based communication is a crude and outdated way of doing things, and they provide a vastly more powerful interface, while keeping the old ones perfectly intact. I've been using MSH for several months now, and I'm amazed at how much more powerful it is than bash (which was previously a god in my eyes).
Unix shell scripts are also incredibly good at manipulating text files, using awk, grep, sed, cut, etc. I tried to do such a task with PowerShell and found it wanting. I revered to Windows Services for Unix (basically the Korn shell).
For those who don't know, a monad is a notion in functional programming languages that is a way to structure computations in terms of values and sequences of computations using those values. Monads allow the programmer to build computations using sequential building blocks, which can themselves be sequences of computations. This is not dissimilar to how PowerShell works, but really, I when manipulating text files, I don't want to be dealing with functional programming language abstractions.
Easily the oddest spelling of "simple and effective" I've ever seen.
Or, to thug Rob http://landley.net/'s sig,
"Never bet against the cheap plastic solution."
Redmond's non-grasp of the wisdom of that observation is simply...titanic...
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Although I haven't played with it, I've read a bit about this shell, and there was something that bothered me about it, and I finally just put my finger on it: this thing was designed by programmers.
.Net libraries are vast and complex... looking at some of the sample msh scripts, I understand how a windows programmer would think they were an amazingly powerful simplification, but damn there's a lot I have to know to get basic things done.
.Net code in my life, I see almost nothing familar when I read .msh scripts. It appears to require an entirely new body of knowledge to do simple things, and bears little or no relationship to the interfaces and paradigms I use day to day. Yes, I know those interfaces are graphical. Seems to me there's bound to be some way to do it (or would be if there were any logic or consistency to the organization of the everyday administative interfaces in Microsoft's products).
I know that the line between "programmer" and "system administrator" is often blurry. And the line between "shell" and "interactive script interpreter" is as well. But when you start requiring people to understand concepts like objects (which may seem like old hat to a programmer), you're already presuming a relatively sophisticated understanding that an "average user" has no grasp of. And the
Ye olde csh and sh are great because they provide a simple way to put programming logic around the set of operations users spend their entire day in and are already familiar with. The learning curve is very incremental: you can master the basic UNIX commands, and then start to add in variable subtitutions (!$ anyone?) and loops (foreach) and such as needed.
In other words, the jump from basic UNIX user knowledge to simple scripting is very small, because the scripting is presented in *exactly* the same context and using the syntax the user does day-to-day work in. But as a competant windows admin who doesn't know VB and hasn't written a line of
Don't get me wrong... I understand that the goal of an intuitive scripting tool is in many ways at odds with providing a rich and powerful development environment that can complete with something like perl, but I had hoped there was something a little closer to "ground level" coming.
-R