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."

can you?

Can you resize the window and copy and paste easily into the windows. If so it's already 10 times better then CMD.EXE.

Re:can you?

You can do both with cmd.exe ... check the properties of the window and adjust the buffer sizes to your taste. I use 132X9999. Turn on Quick Edit Mode for right-click paste actions. And, if you want, you can also drag a folder from Explorer into the window to copy-paste the path to the command line.

Re:can you?

Be sure to turn on tab-completion [nada.kth.se] while you're at it (it's not the best tab completion in the world, but it's better than nothing)

Re:can you?

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.

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.

Quick resize

For 90 cols x 60 lines, try

mode 90,60

Re:can you?

while we're giving out CMD.EXE tips, try this:

enter a few commands
then press F7 for surprising results

Text

Contrary to cmd.exe and Unix/Linux shells it operates on objects, not text when passing data between scripts and executables.

Why would you want to use an arbitrary, difficult to debug format like text when you could use .NET objects?!

-Peter

Re:Text

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.

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 .Net
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 .Net bindings for Perl, that may be an even better choice for a scripting language.

Re:Text

"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?

Re:Text

"Why does the entire world have to look like a scripting language from an OS designed four decades ago?"

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 /dev and operating system internals in /proc can both recieve and output data via text from the shell!

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 /proc in unix.

Its really all the same to me and just another implementation of the shell from unix.

Why?!?

Why does the entire world have to look like a scripting language from an OS designed four decades ago?

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?

Re:Text

They purposefully [for instance] use the wrong direction on the slashes to make things incompatible. That's the level of stupidity they stoop to.

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 /. Thus, they went with the next nearest thing, \.

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 .NET] within bash or tcsh or whatever. That way you could still use the familiar but then extend into .NET crap if you wanted to.

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.

Re:Text

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).

Re:Text

crude and outdated

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...

Re:Text

Our cheif weapon is strings, strings and objects. Our TWO weapons are strings, objects, and JIT bite code.

"Amongst the vast array of .NET objects is the ever popular System.String,....."

Nobody expects the command line!

Re:Text

Currently reading: CLASH - Common Lisp As SHell.

Objects? We don't need no stinkin' objects!

Re:Text

Yeah, me too. I don't know, but the last few days, Slashdot seems to have attracted more dumbness than usual.

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.

The relevant quote...

Ahem:

Those who do not understand Unix are condemned to reinvent it, poorly.

Re:The relevant quote...

I belive they have. It's called linux.

Re:The relevant quote...

I've used MSH on and off for the past 2 years or so, and I can attest to it being powerful. I'm not a big bash scripter but this sure makes some things easier than what I've experienced in Linux shells.

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 .NET code). What used to take a split second can now easily take orders of magnitude longer than the script itself takes to run. Plus, it runs inside the old cmd.exe - this means we're still stuck in a non-Unicode world. Good luck trying to run some quick database queries in non-ascii!

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.

How long will it take for them to create a CPAN?

Probably never, would be my guess, but one of the things I find annoying is how much reinvention-of-the-wheel Microsoft gets away with and yet continues to make the ridiculous claim that they're innovating, when in fact they're merely catching up. Bill Gates, welcome to 1994.

Re:How long will it take for them to create a CPAN

RTFM mate. This is not reinventing the wheel. It's adding a few more spokes, better tires and tougher rubber.

Re:How long will it take for them to create a CPAN

Except the spokes are perpendicular to the old ones, the tires are on the inside and the rubber melts at high speeds.

Dynamic horizontal resizing!!!

When will the Windows command line finally have this?

but but but

We WANT Linux/Unix shells...they work just great, and have lots of tool support...and have lots of good documentation...and have 20+ years of abuse.

Re:but but but

We WANT Linux/Unix shells...they work just great, and have lots of tool support...and have lots of good documentation...and have 20+ years of abuse.

Well, what's stopping you? install one [cygwin.com].

- Oisin

Is that like PowerGlove?

If so, sign me and Fred Savage up!

i don't get it.

Is it just me or does it seem insanely odd that a "shell" for an OS is a) shipped seperately and b) doesn't use text as a native data type? Maybe I'm stuck in the "past," but I always saw the shell as the barebones method for a user interact with an OS. Either this really is cutting edge (object data types) or this is just a hyped-up .NET application that is designed to *look like* the shell.

Re:i don't get 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.

On XBox Power platform? Passing Text Arrays?

I wonder if the trademark works. They will probably have to call it Power Microsoft Shell. People will likely want to have Unix-like piping of textual results. Does this mean a Text array gets instantiated, or is it a stream object?

So basically is Visual Basic 6 all over again?

This sounds very disturbing.

Passport ID required to download?

No thanks.

More like WMIScript

Seriously. Look at the sample scripts [microsoft.com]. Every last one of them looks like this:

$strComputer = "."
 
$colItems = get-wmiobject -class "Win32_UTCTime" -namespace "root\CIMV2" `
-computername $strComputer
 
foreach ($objItem in $colItems) {
      write-host "Day: " $objItem.Day
      write-host "Day Of Week: " $objItem.DayOfWeek
      write-host "Hour: " $objItem.Hour
      write-host "Milliseconds: " $objItem.Milliseconds
      write-host "Minute: " $objItem.Minute
      write-host "Month: " $objItem.Month
      write-host "Quarter: " $objItem.Quarter
      write-host "Second: " $objItem.Second
      write-host "Week In Month: " $objItem.WeekInMonth
      write-host "Year: " $objItem.Year
      write-host
}

So, we can query the Windows Management Interface, and we can write it to the console. Awesome.

Guys, next time, think about making it do something before you put out a release candidate.

Re:More like WMIScript

Unfortunately a lot of the examples on ScriptCenter are direct translations of VBScript examples. This is good in the sense that it shows how a VBScript user can migrate stuff to PowerShell. It's not, however, a good illustration of how PowerShell works. The above script can simply be written as

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

Re:More like WMIScript

I can't believe no one picked up on this comment. Mr Payette here is giving us interesting insight into the reasons for the object-orientatedness of the shell.

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?

See! they admitted it!

Windows PowerS hell

I knew it all along!

Clippy?

What I want to know: does it come with a text version of Clippy?

Strains the definition of "shell", kinda

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.

Good name change!

Monad...

Is that like a gonad, but you only have one? And I thought eunuchs had it tough!

What about the applications?

The thing in *nix is that most applications support the shell. They are built for piping stuff in any possible way. Are the Windows applications going to be built with the shell in mind or is this going to be yet another cmd.exe where you have to build your own stuff to do what you want instead of like *nix where you just pipe at your hearts content.

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)

Shells are often used for managing systems and networks. I think that PowerShell will do an adequate job at this, although it seemed to be more complicated than necessary to me.

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

Doesn't appear to be a way to get a copy to look at unless you have Passport which seems to require a hotmail account. I don't have time to read a couple of dozen licensing agreements atm and it looks like if I register I'm basically signing a non-compete license with Microsoft. Not really a term that I am willing to agree to. Has anyone gone through the contracts?

Re:Downloading

It takes five minutes to setup a passport account associated with any arbitrary email address and thus far has generated absolutely zero spam to my email account. You can also sign-up with a "Limited" passport account, which means, you can sign up with no association with any actual email address whatsoever. You end up creating a fake @passport.com address for signing in.

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=4 .0.5610.0&cbalt=www&vv=400&lc=1033 [passport.net]

Extensions...

From TFA:

Designed for extensibility so that independent software vendors and enterprise developers can easily build custom tools and utilities to administer their software.

Looks like it might not be that hard to create a bash wrapper or similar (python anyone?)

And the point is?

First of all, I would have to upgrade from Windows/2000 Professional to Windows/XP Professional. Since this costs money, I'm not terribly interested. My system has enough trouble running all the stuff I run now (2 databases, a web server, an application server, a development environment, etc. etc.). More operating system overhead is the last thing I'm interested in.

Second of all, I get to write scripts in another language that's not portable across all platforms. I've never worked in a monolithic environment, and I probably never will. Cross-platform tools are a requirement.

Third, I can do a lot of administrative programming for Windows in Perl. I imagine python and ruby have similar hooks (haven't checked). For personal productivity I run Cygwin's version of bash on this machine when I'm running Windows, and bash when I'm running Linux. Different people may want different interactive tools. Fortunately there are several cross-platform choices.

Finally, while I've heard about all these productivity gains with C# and .NET, I've not experienced it. I have .NET, C#, and Visual C++ .NET on the Windows side of my environment. What I've seen is that Microsoft makes a credible IDE. The IDE makes simple things easy, and complex things ridiculous. Transferring skills learned in the Microsoft world to any other environment is difficult at best, and pointless for the most part.

Oh - never mind - that's Microsoft's point.

Come kick the tires

I encourage you all to come kick the tires and find out what PowerShell really does/does not do. I think you'll be pleasantly surprised by its power and simplicity and might even like it. Many of us on the team have a deep background in UNIX and brought that into our work. Even if you don't like what we've done, trying it out will allow you to know enough to throw your rocks accurately. :-)

http://www.microsoft.com/downloads/details.aspx?Fa milyId=2B0BBFCD-0797-4083-A817-5E6A054A85C9&displa ylang=en [microsoft.com]

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)

Windows PowerShell RC1 (for .NET Framework 2.0 RTM) x86

http://download.microsoft.com/download/e/8/c/e8ccf 14c-8009-43ad-b953-1b18609cf14c/PowerShell_i386.zi p [microsoft.com]

Obviously designed by programmers for programmers

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.

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 .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.

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 .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).

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

IronPython

Things would just rock when combined with IronPython. You could easily create something like Monad/PowerShell with IronPython, which fully integrates with .Net. Heck you can even use VisualStudio to edit/debug your scripts.

This thread is useless without screen shots

Not to be a heckler or anything, but I'm not convinced. I would at least like to see some screen shots before I give it a try. Secondly, what is this? An object-oriented shell? I'm a computer science student and all pro-Linux, but I would still like to know more information about this shell.

Believe it or not....

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.

"Power" Shell? Microsoft is a bit late...

Apple is already dropping the "Power" nomenclature (ie, PowerBooks became MacBooks). Redmond's photocopier is too slow. :^)

PS? Shouldn't it be PSH?

Pronounced "PSSSSH!" of course.

The other PowerShell

Couldn't they have picked a different name? I've been using PowerShell [sourceforge.net] on Linux for years now. It's a terminal emulator for X11 (like xterm) and is the first result on Google for the word PowerShell. Now a terminal emulator isn't exactly the same as a shell, but I could see some confusion occurring as a result.

The most important question

Can I use ls to get a file listing yet?

i dont like it

sorry. (wait, it's microsoft, why am i apologizing?)

first it's slow. slower than it takes cygwin to load. second, it's too much typing. all the short form aliases are nice, but seriously, remove-item for rm? maybe it's just me, maybe it'll grow on me, but i doubt it. plus, they really should do a google search before coming up with names, the first result for powershell is http://powershell.sourceforge.net/ [sourceforge.net] (the thought did cross my mind)

Good - need a change

Am I the only one here who has spent weeks of work time writing batch and vbscripts to automate operations on Wn2k Servers and networked Windows clients? If this works as advertised (and if I was still running Windows) Id use it.

Its a step in the right direction and anything that extends an admins ability to write effective scripts is a bonus. After all whilst it may have taken me a few days to write some of the more complex scripts that we used it would have taken longer to write an application in VB or C to do the same job.

(BASH is my shell of choice, its because I have an unhealthy obsession with grep...)
nb Not spell checking this post - its too early

It's all in the name..

One wonders why they chose to change the name... the open source/gnu movement would have called their copy Gonad!

Maybe we can learn something from that

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.

Exchange 12

Why is it going to debut with Exchange 12?

Are they expected email admins to go nuts creating new scripts now? Seems like it's not exactly their target audience...

Amazing Microsoft shell skillz!

If you look at http://blogs.msdn.com/powershell/archive/2006/04/2 5/583272.aspx [msdn.com] you can see examples of why this PS is better than ksh. They seem to have deliberatly tried to make the xamples shown as bad as possible for ksh/bash/sh:

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".

Interesting to see the mindset in action

Its interesting to see the windows mindset put into action in a shell like fasion.

FTA:
$ ls -l | awk '{ tot += $5; print tot; }' | tail -1

This reduces the complexity, but requires specific knowledge of a new language, the language that is associated with the awk command.

The MSH loop is similar; each file in the directory is needed, but it is far simpler as the information about the file is already retrieved:

MSH:

MSH> get-childitem | measure-object -Property length


Yes, but using awk like this will work for any similar problem only requireing you to think about the format of the output, whereas this other way requires specific knoweledge of possible properties. I can see some advantages, but don't assume its better because you dont need to learn a new language, cause you basically do.

Convergence

Ok. I will be rated troll like last time, when I said that Debian is a very good platform for customized distributions (it was before widespread successes of ubuntu and mepis).
I see that both families of systems - the Unix heritage (Linux, Solaris, BSD less so - they are more true to the original Unix, maybe with exception of dragonflyBSD and Darwin) and the VMS heritage (I mean Windows here) are converging. The aim seems to be a kind of thread based, light-kernel operating system, that can be easily parallelized/or distributed, with object oriented interface at both Kernel and User levels. The Unix was taken in this direction by Plan9, Mach and NeXT.
Think I am a loony? look here: Plan9 shell introduction [bell-labs.com].
Unix shell (text) ---> Plan9 shell (arrays of strings) --> Microsoft shell (objects).
I'm also certain that there will come time when Windows will become Open Source, like Solaris. Not that I like Windows or whatever but Open Source is more functional, so the convergence process will also take Windows in that direction.

Another Microsoft "innovation"

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.

Wow. It took them a long time to copy AppleScript [apple.com].

For those interested in UNIX like shell on windows

I am working on a unix like shell for Windows that includes a more modern UI. If you are so interested check out www.undeadshell.com. I am still developing it so its a little rough around the edges.

*NIX Response?

I wonder if the open-source community will rise to the challenge of providing something as good for *NIX, or if they will simply live in denial of MS's genuine advancement/advantage. I think that we now need to update all of our *NIX/Windows Advantage/Disadvantage tables and move the "scriptability" check to the other column.

It's not even clear that you could create something similar for *NIX given that MSH is build on .Net so actually has lots of Objects to script whereas an Object-based shell and *NIX would be lacking any Objects to script. Actually, UNIX is an OO system in a very limited fashion, be it one with only one interface: File.

I asked James Gosling whether the Solaris team at Sun was doing anything with Java to add MSH-like capabilities to Solaris. To make a long answer short, he basically said "no".

Many of the high-order functional programming aspects of MSH remind me of a UNIX shell from around 1990 called "Es". You can read about it here: Es: A shell with higher-order functions [webcom.com].

NDOS / 4DOS / 4NT has been around for 15-20 years

And I see no reason to switch to something new.

http://www.jpsoft.com [jpsoft.com]

I've had aliases, tab-completion, and much more ... since the 1980s I believe. Objects are nice, but I never use cmd.exe anyway!

REXX? AppleScript?

In other words. An OOP shell.

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

Re:How much will it cost?

It will be a general download to the OS as well. It's just that the admin scripts shipped with Exchange will rely on it.

Stereo-typical rhetoric[sic]?

Where do you see ANY indication that this will cost you $? For god's sake, can we please stop the nonsensical MS bashing?

Re:How much will it cost?

Shame you didn't RTFA, you'd look smarter.

Re:Vista: Includes Free RootKit!

Hm, what kind of security do you expect in a shell? But, IIRC, you can run scripts under any .NET permission set, which means that you can emulate stricter permissions than the user you are running under (just like the Java VM does). I think there is also some code signing possible, but it's always a tradeoff, isn't it? It's not exactly like you want to log into some kind of stealth mode to just sign a script you have edited.

Re:Kinda reminds me of Access

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.

Re:Vista: Includes Free RootKit!

The parent is a technical question about the newly released technical solution that the slashdot story refers to. What variety of crack is so powerful that ANY mod could have possibly considered the parent post offtopic????!!!

Re:It's not cost.... It's not a Re-invention

Yeah. The script kiddies want to manage your code. Duh.

Re:.Net rocks

There, I said it.

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.

Re:.Net rocks

Bash or Perl? How about comparing C# to something that's actually in the same league, ie. Java?

Re:.Net rocks

Why does .NET kick ass? I program in C# daily. It is Java, redone decently, with a couple extra features but without some of the polish that Java has. It's nice for a scripted language, but it's by no means revolutionary. Hell, Java isn't revolutionary. .NET is another iteration of a concept that has been around since the 70's, and it has the same advantages and disadvantages that all VMs have. Nothing much to see here. Give me a reason why it's the dog's bollocks, because I really am curious.

Re:Vista: Includes Free RootKit!

It's a legitimate question. The security of PSH is mainly two-pronged: first, as in every other console/shell, including cmd.exe, commands and scripts can only act with the permissions that the current user has. This is the standard *nix way of doing things, and it should be far more effective in Vista once proper LUA is finally well-implemented. The other prong is a combination of security features. First, there will be no default associated file type for PSH scripts, meaning that by default, it is not possible to double click a script file and have it run, like you currently can with .BAT files. You can always create an association, but the default behavior is to instatiate the shell first, then run the script with a command-line command. Second, by default, scripts in the current director must be explicitly invoked (equivalent to not having "./" in your PATH). Third, PSH will support code signing, so that scripts must be digitally signed by a trusted publisher. This can, of course, be yourself, because you can easily enough create a cert and trust your own certificate. But it would prevent a lot of trojan attacks.

Re:Vista: Includes Free RootKit!

Microsoft must have many people covering slashdot who have somehow gotton moderator points, for this the parent's comment to get modded 'troll' and 'offtopic'. I just ran into an obvious microsoft shill over on bugtraq. I suppose if I had as much cash as they did, I'd do the same thing. I wonder what the job title is?

I guess the parent must have struck a nerve...