Slashdot Log In
Microsoft PowerShell RC1
Posted by
ScuttleMonkey
on Tue Apr 25, 2006 04:48 PM
from the new-syntax-to-learn dept.
from the new-syntax-to-learn dept.
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."
Related Stories
[+]
Monad Shell Removed From Vista 330 comments
hggs writes "According to Stephen Toulouse at Microsoft, because of the possible virus threat that targets Monad the shell will not be included in Windows Vista. CNet is reporting that, even though Monad is not to be included on Vista, it will be included on a major server operating system for servers from Microsoft. Codenamed Longhorn server, that edition is due out by 2007." Update: 08/06 04:45 GMT by Z : As Mr. Toulouse states here, the submission here adds one and one and gets three. Monad hasn't been in Vista for about two months. The CNet article is clarifying a previous report stating that Monad could potentially be the first source of viruses in an OS which incorporated it. The interesting news about Monad in the server edition was obscured by the factually incorrect submission, which at first blush seemed to make sense. Mea Culpa.
[+]
Developers: Microsoft Releases A New Monad Command Shell Beta 126 comments
Watercooler Warrior writes "Slashdot originally broke the news that a new Microsoft command shell was in the works when a reader noticed a suspicious job posting by Microsoft India. Today Microsoft released the first really usable version of the shell (codenamed Monad) to beta testers - and anyone who carefully reads the WinHEC slides about Monad will find how to join the beta and get a peek at it. The shell looks like a bunch of old-school Unix and Perl hackers were given free rein to do what they wanted with the .NET framework, and from what is known about the backgrounds of the Monad developers this is probably pretty close to the truth."
[+]
Technology: Next-gen Windows Command Line Shell Now in Beta 668 comments
Suddenly_Dead writes "Microsoft's new command line shell, MSH or Monad, has entered the beta phase. Channel9 Wiki has information on how to download this (complete with Guest ID), and other related info."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
can you? (Score:4, Funny)
Re:can you? (Score:4, Informative)
Parent
Re:can you? (Score:5, Informative)
enter a few commands
then press F7 for surprising results
Parent
Re:can you? (Score:5, Informative)
Parent
Re:can you? (Score:5, Funny)
It certainly isn't what it should be... But, if you go to properties, and go to the layout tab, then change *both* the horizontal buffer size and the the horizontal window size, it works fine. It's just buried on the third tab of the not-very-obvious properties window -- don't confuse it with the buffer size setting on the first tab, as this is unrelated.
Now, why in the name of god they don't just let you resize it with the mouse like every other Windows window, and every other terminal emulator like kterm/gterm... I have no god damned idea. But, it is there, pointlessly buried. Third tab of the non-obvious properties window, where you have to change two different settings by hand. People keep asking me why I don't prefer Windows. They keep insisting, "Isn't Windows easier to use?" Egad.
Parent
Quick resize (Score:4, Informative)
Parent
Re:can you? (Score:3, Informative)
One nifty feature though, is that you no longer have to type the drive letter first to change to a directory on it.
In other words cyou can be in "c:\foo", and just type "cd d:\bar". You used to have to type "d:" and then "cd d:\bar".
Re:can you? (Score:3, Informative)
You can do that in cmd.exe too--
C:\Foo> cd
D:\Bar>
Re:can you? (Score:3, Funny)
Beats me why this should offer any benefit, but you can do it in THREE DEEE!
Text (Score:4, Funny)
Why would you want to use an arbitrary, difficult to debug format like text when you could use
-Peter
Re:Text (Score:4, Funny)
Currently reading: CLASH - Common Lisp As SHell.
Objects? We don't need no stinkin' objects!
Parent
Re:Text (Score:5, Insightful)
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
Parent
Re:Text (Score:5, Insightful)
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?
Parent
Re:Text (Score:4, Insightful)
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.
Parent
Why?!? (Score:5, Funny)
Wheels -- thousands of years old. Still work.
Fire -- hundres of thousands of years under human control -- still works.
And you -- still typing after all these years, over a hundred now, since the invention of the keyboard. Still using fonts, for pete's sake, on graphical displays, invented before UNIX, along with mice, still using silicon (60 years old) and rust (thousands of years old) and electricity, back before Mr Franklin's experiments with kites 250 years ago, still using bits for storage as characters, processed by computer instructions, over 50 years old. Why haven't you graduated to something modern?
Parent
Re:Text (Score:5, Interesting)
When MS-DOS was first written, there was no such thing as directories. Everything lived in the root, and there was no need for path names or path separators. It quickly became necessary to pass arguments to commands, and the natural way to do this was to distinguish them from paramters by pre-pending a character. MS chose to use
Time passed, and directories were invented. People started to use / as a path separator, in similar fashion to how references are built up - eg major part/minor part/whatever/etc, say "57b/6". MS obviously had to support directory trees, but didn't want to break backward compatibility (something they are loathe to do to this day), and so could not use
Alternatively, perhaps you're right, and they're petty and stupid enough to shoot themselves in the foot by making themselves incompatible with every competing product at a time when they had little or no compelling advantage.
Incidentally, try using / in a path in the address bar of Windows Explorer in a modern Windows (eg >= 2k). You might be surprised.
There is no reason why they couldn't embed C# support [or generically
What familiar? This isn't aimed at Unix admins, this is aimed at Windows admins, and most of them are going to be much more familiar with cmd.exe than with bash, or ksh, or ash, or tsh, zsh or any other of the myriad, subtly-incompatible *nix shells.
Parent
Re:Text (Score:5, Insightful)
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).
Parent
Re:Text (Score:4, Insightful)
Easily the oddest spelling of "simple and effective" I've ever seen.
Or, to thug Rob http://landley.net/ [landley.net]'s sig,
"Never bet against the cheap plastic solution."
Redmond's non-grasp of the wisdom of that observation is simply...titanic...
Parent
Re:Text (Score:4, Funny)
"Amongst the vast array of
Nobody expects the command line!
Parent
Re:Text (Score:4, Insightful)
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.
Parent
The relevant quote... (Score:4, Insightful)
Those who do not understand Unix are condemned to reinvent it, poorly.
Re:The relevant quote... (Score:5, Funny)
Parent
Re:The relevant quote... (Score:5, Interesting)
The big thing is- who wants to wait 4-5 seconds for their shell to launch? And this is in 64-bit with 2 gigs of RAM and MSH ngened (ngen == cache of pre-JITed
It's an admirable attempt but I think it's far too slow for normal use- until they fix that I can't imagine it picking up much of a following.
Parent
Is that like PowerGlove? (Score:5, Funny)
i don't get it. (Score:5, Interesting)
Re:i don't get it. (Score:4, Insightful)
Parent
On XBox Power platform? Passing Text Arrays? (Score:5, Interesting)
More like WMIScript (Score:5, Interesting)
Guys, next time, think about making it do something before you put out a release candidate.
Re:More like WMIScript (Score:5, Informative)
get-wmiobject Win32_UTCTime
WMI is one of the reasons we needed an object-based shell - it presents Window management information as a collection of objects. Writing code to render those objects to strings and then parse them back into objects is not realistic. We needed a shell that could deal with them directly.
Bruce Payette
PowerShell Technical Lead
Microsoft
Parent
Re:More like WMIScript (Score:5, Informative)
As I understand it, the difference between PowerShell and your typical Unix shell is that the Unix OS is built around the shell and PowerShell is built around the OS.
As text exchange of data is the de facto way of piping data between applications in a unix system and the shell has long been the de facto way of interacting with the OS and the applications running on it most applications and the OS itself have been built to interact very well with the shell.
However, on windows, which hasn't been built around the shell and which presents objects as the standard way to share data, they had the choice of either
a: adding functionality to all applications in order to allow it to interact in a text-based way with cmd.exe, which is rediculous because of the vast number of applications already out.
OR
b: writing a shell built to integrate with the OS and the objects it uses to exchange data, which they did with PowerShell.
Basically, this seems a sound design decision which probably has it drawbacks (necessity for data type handling & such ) but seems like a good match for winOS'es. An object orientated shell would probably not work very well with a unix OS, if only for the fact that (most?) unixes are written in C, which does not do objects at all.
Seems like a good solution for windows systems, too bad it isn't (won't be?) included with the OS by default. It might make windows a better place to live for all us CLI types, and it can't possibly be worse than cmd.exe, can it?
Parent
See! they admitted it! (Score:5, Funny)
I knew it all along!
Clippy? (Score:3, Funny)
Strains the definition of "shell", kinda (Score:4, Insightful)
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.
What about the applications? (Score:4, Interesting)
I have also a hard time imaging using objects being easier to understand for normal admins and users.
Also, when exactly did the shell stop to suck and begin to be a good feture? The same second Microsoft made their own version?
I've tried PowerShell (formerly Monad) (Score:4, Insightful)
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.
Downloading (Score:4, Interesting)
Re:Downloading (Score:5, Informative)
The contracts are not any different than what you would agree to with Google, Yahoo, or any other online service provider.
Furthermore, with only accepting the passport license, it's a bit shorter than hotmail's. Try reading it yourself. The TOS is actually very short and easy to read if you're not illiterate: https://accountservices.passport.net/PPTOU.srf?x=
Parent
Come kick the tires (Score:5, Informative)
http://www.microsoft.com/downloads/details.aspx?F
If you'd like to learn more, you can read our team blog at:
http://blogs.msdn.com/PowerShell [msdn.com]
Enjoy!
Jeffrey Snover
PowerShell Architect
DIRECT DOWNLOAD LINK (no passpos) (Score:4, Informative)
http://download.microsoft.com/download/e/8/c/e8cc
Parent
Obviously designed by programmers for programmers (Score:5, Insightful)
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
Parent
Believe it or not.... (Score:4, Insightful)
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.
REXX? AppleScript? (Score:5, Interesting)
I don't know, it sounds a lot more like the REXX and AppleScript way of doing things to me. An application exposes a dictionary of possible actions (rephrased in OO, an application object exposes methods) and passes the results to the next REXX or AppleScript-aware application.
Both REXX and AppleScript predate wide scale adoption of OO, so I might be off-base. It does sound very similar though, and personally I think there's room for both that approach and the classic Bourne shell-style approach.
Cheers,
Ian
Parent
Re:How much will it cost? (Score:4, Informative)
Parent
Re:Vista: Includes Free RootKit! (Score:5, Interesting)
Parent
Re:Vista: Includes Free RootKit! (Score:5, Informative)
Parent
Re:but but but (Score:5, Informative)
- Oisin
Parent
Re:How long will it take for them to create a CPAN (Score:4, Informative)
Parent
Re:How long will it take for them to create a CPAN (Score:5, Funny)
Parent
Re:Kinda reminds me of Access (Score:5, Insightful)
Parent
Re:.Net rocks (Score:4, Insightful)
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.
Parent