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.

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.