What problem did MS solve by creating PowerShell?

Question

I'm asking because PowerShell confuses me.

I've been trying to write some deployment scripts using PowerShell and I've been less than enthused by the result. I have a co-worker who loves PowerShell and defends it at every turn. Said co-worker claims PowerShell was never written to be a strong shell, but instead was written to:

a) Allow you to peek and poke at .NET assemblies on the command-line (why is this a reason for PowerShell to exist?)

b) To be hosted in .NET applications for automation, similar to DCOP in KDE and how Gnome is using CORBA.

c) to be treated as ".NET script" rather than as an actual shell (related to b).

I've always felt like Windows was missing a decent way to bang out automation scripts. cmd is too simplistic in many cases, and WSH is too obtuse (although the combination can be used successfully, I'm not a fan). When I first heard about PowerShell I felt like Windows was finally getting a decent shell that would be able to help with automation of many tasks, but recent experiences, and my co-worker, tell me otherwise.

To be clear, I don't take issue with the fact that it's built on .NET, or that it passes objects around rather than text (despite my Unix background :]), and I'm not arguing that PowerShell is useless, but from what I can see, it doesn't solve the problem I was hoping it would solve very well. As soon as you step outside of the .NET/Powershell world, things quit being nice and cozy for you.

So with all that out of the way, what problem did MS solve by creating PowerShell, or is it some political bastard child as I suspect? I've googled and haven't hit upon anything that sufficiently answered that for me, but the more citations the better.

Answer 1

Powershell was actually built as several things: A mature and extensible automation platform and a modern administration shell.

The former is primarily used for the administration GUIs for Exchange and other server products of recent times. The GUI is just a wrapper around Powershell which does the heavy lifting behind (kinda like UNIX GUI programs come to be, as a wrapper for a commandline program).

Jeffrey Snover (Powershell inventor) elaborates a little on how Powershell was created with which goals and problems it should solve.

In my opinion, Powershell as a shell is clearly intended as a replacement for cmd (easy to see) and WSH (WSH didn't get much attention in recent years, even though it had similar concepts as .NET back in its day [one platform, multiple languages with ActiveScripting], but with .NET MS basically put that to rest and resurrection probably wasn't an option for them).

It unifies most aspects of Windows administration in common concepts and methods you only have to learn once. Also, the power in PS for me stems greatly from it passing around objects which might explain why you get into problems when you step out of the .NET/PS world where you only get a String[] from a command. But for many things you would call an external program for in cmd there is a cmdlet which will do it for you.

Answer 2

As a developer, I can tell you I no longer have a bunch of ConsoleApplication42 projects laying around in a folder.

As a developer at a small company where I pretty much do all things IT (DBA, manipulate routers, pull call detail records from the switch, monitor and graph bandwidth for customers, etc...) I can tell you that PowerShell fills a sorely needed gap in Windows and the fact that it's built on .NET provides a seamless upgrade path when the PowerShell pipeline is too slow to handle millions of iterations or a more permanent, strongly typed implementation is needed.

Anyway, I guess the question is why are you switching to PowerShell if you don't have a pressing need? I mean it's good to learn it now since it's basically the new management interface for all things Microsoft. But if that doesn't affect you then don't bother if you don't think you're gaining anything.

EDIT (In response to comments below)

It sounds like you're trying to use the .NET Process class to launch an exe and redirect it's stdout so it can be read by the caller. I agree that is a pain in .NET but fortunately PowerShell does all this for you pretty simply. As for capturing the result and still writing it to the display, that's pretty simple too though the command isn't a very well-known one because it isn't used that often. Here's an example:

# I always find it easier to use aliases for external commands
Set-Alias csc C:\Windows\Microsoft.NET\Framework64\v3.5\csc.exe

# Create some source file
Set-Content test.cs @"
class Program {
    static void Main() {
        System.Console.WriteLine("Hello World");
    }
}
"@

# Call CSC.EXE
# the output of csc.exe is written to results.txt and piped
# to the host (or select-string if you prefer)
csc test.cs | Tee-Object -file results.txt

# Check for errors
if ($LASTEXITCODE) { 
    # this is where community extensions would come in
    # handy. powershell 2.0 also has a command to send
    # mail but in 1.0 you can grab one from poshcode.org
}

Answer 3

If you're looking for something to automate some tasks like that, check out AutoIt

Answer 4

IMHO the main advantage seems to be a sensible cut and paste in the command console.

Otherwise I use ActiveState perl for scripting on windows. Way more powerful than any windows shell script, and the OLE interface exposes the whole windows API in an easy to use way.