Yep, it has some interesting features/capabilities but the syntax is soooo baroque. All I want out of shell is a means to get boring shit done without having to think about it too much. At this point, Cygwin is STILL the way to go on windows and it would take A LOT of simplification to make powershell even competitive on windows, let alone competitive on *-nix platforms with a plain old shell like bash.
There are some very powerful commandlets (basically scripts) for control over various pieces of MicroSoft infrastructure components (Exchange, Active Directory and more). Having access to these commandlets on my favored environment would be useful. I wouldn't even need to be running a PowerShell session to run them, but that would occasionally be nice too (there is something to be said for object pipes).
This isn't pointed at you, keyle, but here PowerShell seems to be one of those things that's universally panned by people who don't understand it, or who refuse to give a serious chance to anything that isn't a traditional Unix shell...
To answer your question, PowerShell's big win is that it's an object-oriented shell on top of .NET. Where the Unix shell pipes flat data, PowerShell pipes .NET (and COM) objects.
In practice this means things that may require complicated and often fragile text-wrangling in the Unix shell are straightforward and robust in PowerShell. For example, suppose you wanted to kill all processes with a private working set greater than 1 GB:
ps | ?{ $_.PM -gt 1GB } | %{ $_.Kill() }
Here ps returns a collection of all current processes, then pipes it to the where-object cmdlet (abbreviated "?") which filters the collection to those with a private working set greater than the given size. The filtered collection is then piped into the foreach-object cmdlet ("%") which invokes the Kill() method on each object passed in – these are real .NET objects being passed around, so you can invoke methods, set properties, etc.
You can get the same result with a Unix shell script, but you have to be careful to count the columns output by ps correctly, skip the output header, pass it through awk, save the corresponding PIDs and then invoke the kill command on them... and then it all breaks if you run it on a different Unix system where ps outputs a different formatting. In practice you usually leave the shell environment and write a Perl or Python script instead for this sort of thing.
In PowerShell you can directly instantiate .NET and COM objects, and you can implement your own cmdlets and modules either in the PowerShell scripting language or in any .NET language like C# or F#. So e.g. you can access the .NET class libraries to get the time as so:
[System.DateTime]::Now
And this makes PowerShell handy for interactively developing .NET class libraries (at least until C# gets a real REPL, and if you aren't using F# anyway). Of course this object-oriented approach is all the more necessary on Windows, which is inherently an object-oriented system (think OLE automation, WMI, etc., let alone .NET) than it is on Unix-based systems.
Some people will complain about the PowerShell scripting language... and sure, it's not perfect, but I think the team did about as good a job as possible satisfying the various requirements involved in building a new Windows shell language that could be used both interactively and as the basis for writing scripts. Superficially the language is heavily influenced by Perl, and while I'd still rather use Perl for "serious" automation tasks, PowerShell gets the job done... and it's nowhere near as ugly as scripting in the traditional Unix shell, nevermind the old Windows command shell.
For more on the design rationale, in the words of one of PowerShell's creators:
I worked with PowerShell in a past life, and found it quite useful and reasonably pleasant[1] (esp. when coming from standard Windows Shell), however it's this:
In PowerShell you can directly instantiate .NET and COM objects
... that I think will keep it from being especially useful on non-Windows platforms.
Windows has COM objects for pretty much every language/app/platform feature pre-2003, and .NET objects for pretty much everything since. To be equivalently useful, then a ported version would need to find the equivalents on their new platform. That sounds hard to me, especially on platforms like Linux where you have a half-dozen different desktop API possibilities and where the historical focus is on text files, not APIs, for configuration & control.
Without object models to leverage, a PowerShell port will be limited to replicating everything with wrapper objects: starting from Bash functionality, then coreutils, and then slowly working up.
[1] TBH I wish they'd added features to IronPython instead of making a new syntax, but such is life.
> however it's this [...] that I think will keep it from being especially useful on non-Windows platforms.
Sure, and I acknowledge as much in my post above, that PowerShell's object orientation is most appropriate for the Windows environment. But even if you aren't concerned with COM, I still think PowerShell is pretty nice, and I wouldn't mind seeing a port to Linux. So for that reason I welcome its addition to the Community Promise.
> TBH I wish they'd added features to IronPython instead of making a new syntax, but such is life.
I don't think that would have worked well...
You have to keep in mind that PowerShell is intended to be used interactively, and this has all sorts of implications for the language design. For instance when you type
PS > foo
at the PowerShell command line, "foo" may be a pure PowerShell function, but it could also be a cmdlet, or an external command somewhere else on the system. If this were a straight Python REPL instead, you'd have to do external calls differently from Python function calls, like so:
Python > system("foo")
and that gets old real fast. Likewise you need to allow bare strings and ditch parentheses for function calls so you don't wind up saying cd("C:\"). You'd also have to come up with a more succinct syntax for chaining Python generators assuming that's what you want to use as a substitute for PowerShell's cmdlets. Plus there are concerns like, hey, we can't use the backslash as a string escape operator, because suck as it may, that's the traditional path separator on Windows, so we've gotta make it something else. By the time you're done, it's not even Python any more.
And on top of all that: in my opinion, as much as I love Python, significant whitespace really sucks for REPLs...
So I don't think Python would have been an appropriate choice for a new Windows command line interface. But the great thing about PowerShell is that even if it isn't interactive Python, you can always implement cmdlets for it in IronPython (or pretty much any other .NET language)...
