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.
When will the Windows command line finally have this?
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.
Furthermore, what I do with shell is, for example: call a program, catch the output, read in the 3rd column, print that combined some command to the shell again. This is easy when you work with text and you don't have to worry about the variable type of the 3rd column (be it a number, a filename, a date, an executable command). I think you will get in big trouble if all this data has to fit into a .NET datatype, you'll need a lot of coding around (string to filename, integer to filename, etc etc) to get it working, which is not what shell scripting is about!!! I will write a real program if I want to do something tidy like that, my shell script is there to solve a problem quick 'n dirty, thank you very much!
molmod.com - computing tips from a molecular modeling
A "shell" is an interactive layer around the functions that the OS supplies. Because the user has to give commands and read outputs, the natural interface is text, but to programs serialization and deserialization is an expensive chore. Many interactions with a shell require several programs to work together. With an entirely text-based shell, this means a CPU hungry and error prone serialization-deserialization step for each connection between a pair of communicating programs. On the other hand a pure text interface allows for easy debugging and ad-hoc adaption. An object passing shell is first and foremost a performance boost in complex interactions and it also gives the benefits of self-describing data, i.e. no more trying to filter a single datum from a wad of text output with regular expressions. Think shell scripting, without the sluggishness and unreadability.
And couldn't I just write this in C#? I don't get it.
If you think bash is a good language because you can embed perl into it, you seriously need to back away from the xterm and get some fresh air.
> Why would you want to use an arbitrary, difficult to debug format like text when you could use .NET objects?!
Maybe so we don't have to parse and re-parse and re-re-re-parse the damn text every time. To say nothing of data that's nested. Of course we could all just use XML and YAML, we just have to rewrite every app to serialize and unserialize these grotesque formats.
Frankly I don't see the need to justify the addition of functionality for people who do nothing but bitch about how real problems don't really exist. You stick to piping text everywhere, no one's taking it away from you.
Anyway, it'll be cloned it within a month and then the slashdoterati will claim they invented it. Or maybe it'll run on Mono.
Done with slashdot, done with nerds, getting a life.
"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.
You can do both with cmd.exe ... check the properties of the window and adjust the buffer sizes to your taste.
Increasing the buffer size still doesn't let you resize the window horizontally, although it does allow you to increase the size vertically. It's a fixed width window, which really stinks.
No, linux is an implementation of Unix, not a reinvention of it. It's POSIX-compliant. Windows is still fumbling around with basic lessons which were learned by unix professionals years ago. Nothing different than you'd expect from an OS designed for home computers really.
As for monad/powershell... it's the same story. Instead of having the shell of your choice (bash,csh,zsh,python...) with the programming language of your choice (bash,perl,python,C++...) they're still trying to force a vision on people that will probably turn out to be fundamentally flawed in some way.
Am I the only person that thinks piping objects between processes instead of an raw byte stream sounds very, very awesome?
I do a lot of bash and perl scripting and am very good at it. The freedom in transformation that perl gives over plain text is huge.
Extending that data to objects opens up a whole new world of capability in the same way, say, perl and regular expressions opened up whole new capability for munging data. Mmmm... munging objects.
Absolutely, totally cool. Don't be a Microsoft hater just because it's the popular thing to do.
Windows has a different culture to *nix. On *nix, most basic management software is either FOSS, or comes packed with the OS. On Windows systems, you pay for everything.
Everything.
Except IE.
Want file conversion software? Pay for it. Want interface software? Pay for it? Want ssh? Pay for it. Want to do something that is taken for granted in *nix systems and can be done by three different programs running on the system by default? Pay for it.
Let's face it, you can't get the functionality of pico on a windows install without buying or downloading a third party piece of software. And FOSS software is hard to come by on windows, so you're left with the option of paying $15 for a program that reads id3 tags or has syntax highlighting. The danm OS doesn't even come with a compiler.
If you're working in windows, it means you've decided to pay good money for inferior versions of basic tools that come free on a *nix system. Hence, if PowerShell becomes popular, expect companies to repackage csh and bash variants for $500 a pop to Vista admins that have reached the limits of their $50 Powershell.
May the Maths Be with you!
cygwin
BASH shell-scripting kicks ass. So do PERL, Python, the Korn Shell, PHP and C (and it's derivatives). I know enough about all of them to use one or more of them to do most of the tasks I need to do in the timescale I need to do them.
I've never programmed anything in any Microsoft programming environment because I've never needed to - and it would take me far too long to learn their way of doing things from scratch rather than working with what I know.
However, I know a few MS-based programmers who managed to develop the tools they need to in .NET or whatever it is they use - I'm sorry, I'm not informed enough about MS programming environments to voice any more opinions about it.
Suffice it to say, they're happy and I'm happy.
So everything is right with the world.
End of story.
Gentoo Linux - another day, another USE flag.
Looks to me like they made everything take 6 times as long to enter. All the commands are longer. That's what I love about unix, commands are as short as possible. Who cares if they are cryptic. Only people who really know how to use computers are going to use these tools anyway, and these people can cope with learning what ls,grep,cat,cp,rm, and all those other commands do.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Given that 95% of the free tools available on Linux are available on Windows, me think that you've no idea what you're talking about.
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
I'm an avid Python, PHP, Perl, Ruby, and C# programmer.
.NET you can switch from C# to C++ to J# and still use the same common libraries! And if you already know C, then learning C# is a piece of cake. Same for Java and J#. Your "learning curve" comment is totally unjustified as far as I'm concerned.
Ok, those *nix languages are all fine (I particularly am fond of Python), but C# is definitely a very nice language. Give credit where credit is due.
I can tell you from personal experience that I haven't found development/debugging tools in any of those other languages that compare to Microsoft's.
And as for your comment about the learning curve, I totally don't get that. So you have no problem with the learning curve involved in learning Perl, Python, Korn, PHP, and C and yet you have a problem learning c#? Those languages don't even share the same libraries; at least with
I know its hard to accept microsoft did something good, but as someone who has been using betas of this for months, I must say it is pretty darn slick.
Think of how great your linux environment is, becuase you can easily chain together applications that pass textual data between each other... This is the same idea, except we can now pass complex objects and custom data types as well.
To solve the problem of how to 'display' an object, each object type can have an xml file describing how to display it in a text environment.
Big ones, small ones, some as big as yer 'ead!
Give 'em a twist, a flick o' the wrist...
> They purposefully [for instance] use the wrong direction on the slashes to make things incompatible.
Ironically, Powershell (ugh, I think I'll stick to Monad) accepts both \ and / as directory separator characters and uses - as the default switch indicator (/ is still accepted to make lives easier for people coming in from a DOS background)
> My problem is how blatantly incompatible they do everything.
And of course there is one true way(tm) of doing everything. Computing obviously reached its peak during the mid 80s and we should never ever do anything different because, you know, it'd upset the Unix geeks and you know how bad they can be when upset.
Or you could run cygwin on Windows. But I guess it's easier to kvetch.
Anyway -- It's their platform. Powershell is intended for admins running Exchange. Exchange's admin GUI will generate Powershell Commandlets that will let Windows admins package repetitive tasks in a non-programmy sort of way without taking away power and expressiveness from those who *want* to program. But of course, Microsoft should accept an external risk and go ahead and integrate Perl/Python/whatnot into its products because that'd make *you* happy. Who died and made you the Sultan of Brunei?
(As a side note, Microsoft internally has no trouble with Perl. The problem is that its customers (typically enterprises who buy Windows Servers) are quite clear that they want nothing to do with Perl-- primarily because of the CIO perception that Perl is write-only and that Perl code is essentially job-security for the admin that wrote it.)
Go somewhere random
"Why does the entire world have to look like a scripting language from an OS designed four decades ago?"
/dev and operating system internals in /proc can both recieve and output data via text from the shell!
/proc in unix.
Because computers input/output information just like they did decades ago. Unix is simple in the sense that everything can input and output data via text streams. Even the drivers in
Windows is great for grandma, but in an enterprise server room or for a power user its insufficient.
Why can't you manipulate the data inside the computer as easy as you could with unix? Why do I have to know x,y cordinate to click mouse buttons when running batch jobs for Windows programs?
PowerShell is a great idea and its about damn time. Since Windows uses objects it makes sense to use them as arguments as well as text and the WMI which reminds me of sysctrl and
Its really all the same to me and just another implementation of the shell from unix.
http://saveie6.com/
And of course there is one true way(tm) of doing everything. Computing obviously reached its peak during the mid 80s and we should never ever do anything different because, you know, it'd upset the Unix geeks and you know how bad they can be when upset.
:-)] a dive off the sanity train you're fucked. What, you gonna distribute older copies of Monad [say a version you liked] to your clients? I don't fucking think so.
You say that but the only reason people like me like the "oss way" is that it's just that, open. If Larry decides to take a dive off the sanity train I can stick with the current copy of Perl. I have the right to use the code and furthermore distribute it.
If MSFT takes [...
That and yes, bash and the other shells have worked fine for decades. I can embed perl/python/etc scripts directly into a shell script for greater flexibility. Since perl has an 'exec' function I can even send it code or other data directly.
The MSFT way is just "different" but not because they want to do something that is fundamentally better. Just because it leverages their vertical market strategies in a push-pull positive influential manner!
Show me how, for instance, ASP or their other SSI incompatible technologies are fundaementally better than PHP or CGI via Perl.
Show me how their variations on the HTML standards are "better".
Show me how their take on the C and C++ languages is "better".
It's simple economics. If you can isolate your customers from your competition you rule them all. That's all that drives this level of "innovation". I mean if it was really about the technology then where is Monad for Linux? I mean is Monad actually integral to the Windows operating system? Similarly where is Office for Linux?
So people bitch "oh but there isn't $SERVICE in Linux" but I'd still point out the bulk majority of Office applications is just userspace crap. No reason why it can't work in other OSes.
If OpenOffice can run on a dozen platforms and it isn't written by the supposedly "best" people in the world [best being Microsoft] then clearly MSFT is missing something.
Tom
Someday, I'll have a real sig.
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
Virtually communication under Unix is text-based, no matter it's human-to-program or program-to-program. The CLI output/input is text based; the configuration file is text-based; the log is text-based. I think the reason is that most of the stuff is originally designed for human to read: the thing you pipe to another program is initially intended to be examined by human; the configuration and log is also built to allow a human to read, interpret and change them, manually. However, when this human-oriented (or geek-oriented) text is used to glue different programs, it means extra work to parse them. Thanks to awk and the standardization on standard programs like ps, so far, so good.
We actually have already seen troubles with this approach. How many programs have tried to override your xorg.conf/sources.list/sshd_config because they don't have a nice way to just insert a few records and gracefully remove it later? Wouldn't it be better if the configuration system provides API for other programs and, more importantly, scripts to interact with it and a GUI/CUI/curse for human to change it, just like what gconf2 has done?
Maybe it's time for us to put more OO-friendly stuff into UNIX. Apple/OPENSETP has been along the OO-based API road for like 10 years, and MS is trying essentially the same thing with .NET. It's true that we have a lot of OO goodies on UNIX like python and ruby. But the problem is that they are at a higher level, and therefore if you want a python program to interact with ruby, you have to dump your object into text and parse it back into object representation at the other end. It would be nice if we could have some lower-level object layer or simply standardize an object serialization scheme.
It's true that intercommunication with objects is more efficient and flexible for computer programs.
Tom uses Perl 5. :-)
That's my point exactly though. Larry is free to turn Perl into whatever he wants. The code is freely accessible. I can keep giving Perl 5.xx to my customers and not care what 6.xx does.
Furthermore, if I'm so inclined [I'm not... but] I can fix and add to Perl 5.xx if Larry [and the others] decide to abandon it.
Whereas in the MSFT world you're basically fucked. Reported bugs [especially in IE] often go unattended for long periods of time [CWS virus anyone?] and newer versions are often ever so slightly incompatible with previous versions of the same tool.
If people really can't see MSFTs approach to "segment, divide and conquer" development then they really deserve what they get.
Tom
Someday, I'll have a real sig.
Why would you want to use an arbitrary, difficult to debug format like text when you could use .NET objects?!
Whether you like to admit it or not, text is an arbitrary, difficult to debug format. If your data are structured, then that structure has to be encoded somehow in the text. And everybody and his uncle has a different preference as to how to do that encoding.
Maybe so we don't have to parse and re-parse and re-re-re-parse the damn text every time. To say nothing of data that's nested. Of course we could all just use XML and YAML, we just have to rewrite every app to serialize and unserialize these grotesque formats.
... Pathetic.
Do you understand that the shell is suited for system administrators and not for programmers ?
Well, programmers can use it too, that's a powerful feature, not a drawback.
System admin don't need to parse and reparse and re-re-reparse anything.
No BS about nested data either.
Frankly I don't see the need to justify the addition of functionality for people who do nothing but bitch about how real problems don't really exist. You stick to piping text everywhere, no one's taking it away from you.
To add functionality, the basics should be there. Do you understand that the shell does not just pipe text ? It does far more than that, it is portable and even helps boot some OS, you know. And in this case, piping is one minor feature, environment and managing jobs is far more important.
Anyway, it'll be cloned it within a month and then the slashdoterati will claim they invented it. Or maybe it'll run on Mono.
And a troll to add credibility to your argument
And modding all those posts off topic would drain the supply of mod points so quick the whole universe would disappear in a puff of division-by-zero, which is too bad.
What we have here is actually fascinating. It's an entirely new way of looking at the command line. It moves from the file based systems we've used since computing began, and instead looks at the high level programming and works within that framework. I think that's great, personally. If Microsoft could produce an operating system that eschews Win32/Win16/DOS et al completely and is pure .NET, with this as the shell, they would be producing something entirely radical and interesting at the same time, something that may well end up being several orders of magnitude more usable and useful than the Unix-based competition.
I'd have appreciated a good discussion about it. As it is, I guess I'll have to wait until John Siracuse does an article for Ars Technica on the subject, and I'm not certain he will.
You are not alone. This is not normal. None of this is normal.
Examples 3
Find the total bytes used in the current directory
The example is a 6 line script in ksh, or, a 3 step pipeline using awk to do the following:
du -b .
Hmmm...
Example 5
Find out when a process is no longer running.
The example shell script is 11 lines long, features two tests and two pipelines into variables to do the following:
while
ps -e | grep application ; do
sleep 10
done
echo "not running no more"
These are just two - I can see simple little pieces of shell that are trivial to make work on any modern posix system for all the examples provided, except for the laughable
Example 6
where they (Microsoft's rather amazing ksh coders) say there's no way in Unix to see what version of the code is running. Well yes, it's not the shell's job to keep track of that, but anything written using gnu getopts or written by anyone who actually keeps track of versions uses '-v' or '-V' to display that information.
The so-called examples page I linked to is really a page that is designed to convince Windows-only people that they can now have the power we have been used to for 20+ years. Anyone who actually has written any scripts bigger than "echo 'Hello World!'" would be laughing at their examples of "Unix Shell Scripts".