PowerShell vs. Unix shells

Even with the UNIX subsystem installed?

> However, PowerShell is still treated as a second class citizen in the Windows eco-system, and that is, imho, its biggest weakness.

I don't know about that. Microsoft operates NuGet (the .NET equivalent of NPM or Gems) and the way of downloading packages is through powershell (albeit a specially docked version inside Visual Studio).

I agree that it's treated as second class in that most utilities are not designed with it in mind first but I can see that changing over time. They are already excellent Powershell equivalents of Make and Apt/Yum by third parties. Third parties have embraced it pretty strongly.

Powershell creator's deep UNIX background is evident in its design - they have actually fixed many important problems with most UNIX shells. Some of which are:

- Moving from a text stream manipulation to structure content. No more worrying if separators need to be escaped within the content each time.

- More powerful programming constructs like: Lambda functions, parallel assignments

- Signed scripts

Even though it might not be superior to other shells in every aspect, Powershell's tighter OS integration and OOP approach makes it one of the best shell available on the Windows platform.

Good news: the startup time is largely fixed on PowerShell 3 (Windows 8). Most of that startup time ends up being PowerShell trying to load all of the snapins on your system--and you can have a LOT of them if you're a developer, since there are snapins for IIS, SQL Server, and remote management that come more-or-less out-of-the-box in that scenario. PowerShell 3, rather than actually loading all of these, simply notes what commands they export, and only bothers actually loading the snapins if you actually use them. Up side, PS on Windows 8 takes less time to start up. Down side, commands occasionally pause a second while PowerShell loads whatever snapin happens to have the commands you just tried to use. This ends up being a pretty good trade-off in my daily work, though.

Kind of, but you're doing it wrong.

The bash way to remotely administer a server is to SSH into the server, then run your commands there. While that's technically possible with PowerShell in recent versions, it's not how PowerShell is designed to work with remote machines. Instead, your local copy of PowerShell is designed to grab the remote server's management objects, and use those to administer the remote server.

For example, say I quickly want to shut down a service on ten boxes. On a Unix system, I'd use a tool like Fabric/Ansible/whatever to quickly SSH into those ten boxes and run "/etc/init.d/whatever stop" (or equivalent). I guess you could do this all on one line with something like

    echo box1 box2 box3 ... | tr " " "\n" | xargs -L 1 -I BOX ssh BOX /etc/init.d/whatever stop

but that's really rare, in my experience, compared to using a tool like Fabric.

On PowerShell, in contrast, I'd grab the remote service objects, and pipe them into the Stop-Service cmdlet, locally. For example (written verbosely; there's a shorter way to do this):

    @('box1', 'box2' ... ) | ForEach-Object { Get-Service -name "whatever" -computername $_ } | Stop-Service

Note what's going on: I'm passing an array of box names in, grabbing out handles to the actual services running on the remote box, and then stopping those, using the local Stop-Service cmdlet.

Other things work the same way.

But my favorite part is that Windows servers actually vend a lot of their resources as PowerShell mounts. Changing the configuration of Apache on your server farm? Break out Puppet and some templates on Unix, but on Windows, use the IIS snapin to "cd" right into the IIS configurations on those boxes and use your normal cat/echo magic to change the configurations. Need to change registry settings? You can "cd" into the registries, too. Same for SQL Server. And because this is all through PowerShell, doing things like redirecting a SQL Server database name right into an IIS configuration file (e.g., configuring your website on which DB to use) becomes easy--again, across a pile of machines.

So: yes, you can remote in. But that's not how PowerShell is designed to work, and you're losing a lot of the magic if you do things that way.