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

Comments

REXX? AppleScript?

[mccalli]

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

i don't get it.

[moochfish]

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.

On XBox Power platform? Passing Text Arrays?

[expro]

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?

More like WMIScript

[Anonymous Coward]

Seriously. Look at the sample scripts. 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:Vista: Includes Free RootKit!

[cnettel]

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.

What about the applications?

[miffo.swe]

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?

Downloading

[Lando]

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:The relevant quote...

[PhrostyMcByte]

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.

Re:Text

[Tim C]

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.

And the point is?

[thetoastman]

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.

Re:Come kick the tires

[fade-in]

I hate to admit it, but from what I've seen of PowerShell I've really liked. I like the idea that the syntax for all commands is consistant, and enforced by the framework. No time spent retrofitting old commands to a new standard. Well, I guess you get that for free because you are now building everything from the ground up anyway.

Some of the object-oriented features are quite nifty, and I don't see any of the standard UNIX shells doing that anytime soon. But I guess I'd really have to get into it before an OO shell became much of a *NEED*. Right now, it feels more like a "gee, that's kinda cool" sort of feature that I really don't much care for when performance is a bigger priority. I don't forsee PowerShell one-upping Bash in speed anytime soon, and that's not saying much to the folks who believe that Bash is already bloatware.

Does anyone besides me revel in the irony that MacOS and Windows now feature modern command-lines?