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:More like WMIScript

[tgv]

Unix is not built around the shell. The shell is just a normal executable (program, software, ice, whatever you call it) that uses Unix system calls to become a command interface.

The Unix shell has no knowledge of what the other executables or scripts that you execute with it do and the OS doesn't require text to be passed between programs. The unix philosophy is that everything is a stream of bytes and programs can do with them whatever they want.

The advantage of having a program output text rather than some object structure, is that it's output can be trivially displayed (i.e., without further translation). So, if I type "ls" under Unix, I can read the actual file names.

The disadvantage is that information gets lost. E.g., "ls a*" displays file names next to each other, doesn't display the path name or other information. When you ask it to do so, its output becomes more complex to parse for other programs in the pipe.

It seems the PowerShell tries to overcome this problem by having "ls a*" (or "dir a*.*" :-) output objects instead of text and then doing the translating for you only at display time (correct me if I'm wrong). That way, when you pipe "ls a*" output into another program, that program has all information it needs about the files you were looking for.

If that's the case, the PowerShell is going to be somewhat inconsistent and tricky to deal with for people who are used to the (IMHO simple and elegant) idea that "ls > file; wc file" is the same as "ls | wc".

Re:More like WMIScript

[HawkingMattress]

If that's the case, the PowerShell is going to be somewhat inconsistent and tricky to deal with for people who are used to the (IMHO simple and elegant) idea that "ls > file; wc file" is the same as "ls | wc".

IIRC there is a text serializer which you can use with if all you want is basic text output. so ls | totext | wc would do the same as ls |wc on unix. And if they did things right (didn't tried monad myself, just read some articles about it), they'd have the "commands" have default input and ouput formats, which would call specific serializers. So in this case, wc would default to text input, forcing the command in the left hand pipe to serialize its data to text unless a special parameter is supplied to wc. But i'm just speculating on this one.

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:can you?

[Otter]

OMG, bless you! (For those who don't understand what "check the properties of the window" means, right-click on the title bar.) I see you can drag files to the command line as well, not just directories.

To resume complaining about Microsoft, though -- perhaps they could include a help button or any other visual cue that there's more to the app than a window with a cursor? It doesn't have to be Clippy ("It looks like you're trying to use Unix commands out of habit!") but I wouldn't mind having the cat scratch itself and chase butterflies while SAS runs...

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?

Re:The relevant quote...

[moosesocks]

How quickly we forget history.

Microsoft did Unix back in the 80s, and used it internally well into the 90s.

I would trust Microsoft's Unix knowledge just as well as I'd trust Apple's unix knowledge in the late 90s --- and look at the runaway success that OS X has been.

Don't judge a book by its cover. I'm not the biggest fan of Microsoft, but I'll concede that they've had a number of fantastic successes to their name. Powershell sounds quite interesting and innovative from what I hear -- actually one of the few true 'innovations' to come out of MS in recent memory. I'll look forward to seeing how it works out.

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

[Aladrin]

Okay sparky, here's the problem:

Registration Required for This Download

Okay, so I've got a passport account (please don't mod me down for this, I was young and stupid.) And yet, you can't sign in because passport is freaking out.

I have been DYING for a worthwhile shell in windows. I've been using rxvt and aterm and they just don't match up to a console-only or yakuake session in true linux. I would LOVE to try your stuff. But you have to MAKE IT AVAILABLE TO DOWNLOAD.

Re:I've tried PowerShell (formerly Monad)

[DrAegoon]

I always loved the old "Monad" name but I guess they changed it since no one got the joke. According to this page (second answer) the inspiration came from the 17th century philosopher Gottfried Leibniz. Leibniz proposed the concept of a Monad as the fundamental particle of the mental realm much as the atom is the fundamental particle of the physical realm.

Monads are supposedly self contained and closed off from any outside input. This leads to the joke as I understood it. In describing the concept in his Monadology Leibniz says, "Monads have no windows, through which anything could come in or go out," an appropriate quality for a command shell ;)

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?

Good - need a change

[Ajehals]

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

Re:Text

[boa13]

If I recall correctly they wrote the first MS-DOS manuals using troff/nroff on their own flavor of Unix, so they definitely knew what Unix was, what directories were, and how they were separated on major OS available at the time.

Re:can you?

[moro_666]

i a gree about the powervirus part. since microsoft has quite a bad backlog on security in the last ... emm .. many years, it's quite unlikely that this would bulletproof.

  but hey, it's at least it's the first three-dee virus platform :)