Never played with it, but as I understand it, it creates a lot of flexibility by having absolutely every command or task handled by an object. The downside is that standard Unix command-line is just a set of simple text commands. Easy to parse, easy to understand.

Powershell, even if ported to other platforms, could only find root in a Windows environment anyway, since it needs all those .NET objects to do its thing. A terminal on Mac OS X, for example, does not necessarily need the Objective-C frameworks to do its job. Same for any other *nix variant. Powershell absolutely needs .NET.

I'm neither here nor their on it, but I'd be interested in finding out the experience of anyone who has played with it.

Python.

/thread

PowerShell tries to be both an interactive shell and a scripting language, but fails at being a shell and isn't as good as Perl, Python or Ruby as a scripting language. It changes the traditional meaning of pipes by making piped data and standard input/output different e.g. "'*.txt' | get-childitem" would list all files with a .txt extension, when that shouldn't even be possible because get-childitem doesn't normally read from standard input. It also doesn't support input redirection with < because of its complicated object model when a pipe in all other shells is the same as redirecting output to a temporary file and sending the input to a second command. Piped data in all other shells is just a stream of bytes and is exactly the same whether displayed on the screen, piped to another command or redirected to a file.

>>211
Do you think the awkwardness you describe can be offset by Powershell's ability to manipulate pre-existing COM and .NET objects? Given the massive amount of both, it seems like Powershell might be a good glue language for small automation tasks.

>>212
You can use those with Python too. The ClamAV Outlook plugin is a COM server written entirely in Python.