| The main benefit of PowerShell over other shells is the object pipeline. In classical shells, a pipe basically connects binary stdout -> binary stdin. A pipe between PowerShell cmdlets, on the other hand, can produce .NET objects directly without having to serialize them, so the pipe can connect .NET object producer -> .NET object consumer. If the consumer can't handle objects, the pipe degrades to binary stdout -> binary stdin. For instance, the pipe in `ls | grep` is drastically different from `ls | fl`, because the latter is an in-process transfer of a .NET object collection, while the former transfers lines of text from one process to another, (in this case, to GNU Grep.) Upside: the consumer doesn't have to "parse" stdin to get reasonable data on which it can operate. Downside: if you want to write a consumer, you're stuck in .NET land. (Oh, how I wish I could write a consumer written in python that could advertise that it supports a specific object-oriented serialization on stdin! Then we could write a PowerShell stdin/stdout compatibility layer into python as a module... Alas, I'm guessing this task is reasonably hard.) Oddly, I couldn't find a great readable intro to the topic, but this comes close: http://www.darkoperator.com/blog/2013/1/28/powershell-basics... |
And I don't want to find every .Net equivalent of the command I use in Unix systems. Perhaps all the coreutils have counterparts in Powershell, but for all the other third party ones I use, probably not.