I have been splitting time between PowerShell & bash at work and, so, I have been able to get a little more acquainted with it, which is nice since I have been wanting to ever since my professor (a die-hard bash user) mentioned that Microsoft had just come out with a new shell that was, in some ways, more advanced than bash.
There are some niceties in PowerShell and, in truth, it can mostly be summarized as being Bash.NET or, more likely, Bash#. There are, however, some warts. They are the kind of warts that make one thing abundantly clear: PowerShell was designed by theorists, not everyday users. What I mean is this: some of the usability issues (yes, believe it or not, there is such a thing as usability on the CLI) are so glaringly obvious that the only explanation for them is that the designers were theorizing as to what someone who used a shell would want, rather than how they themselves would use one. Let’s run through a few examples.
Execution of script files is off by default. For anyone who has used any of the Unix shells, this almost incomprehensible. One off scripts, far too long to be typed command by command in a running session, but short enough to be dashed off in minutes, are the order of the day. The idea is that, by default, you cannot actually run PowerShell scripts is just astounding. To get scripts to run, you must either launch powershell.exe with a switch modifying the policy for that particular session (i.e. something like
powershell.exe -ExecutionPolicy Unrestricted
) or by using the Set-ExecutionPolicy commandlet. The latter, however, modifies the registry and so requires a reboot.
Next, we have the common house-keeping task of setting permissions. Sysadmins do it all the time. In PowerShell, the process to do this mundane task is absolutely daunting. (Note: there is a DOS Command attrib that will fulfill a similar function with much less headache. However, we are trying to judge PowerShell on its own merits, not on the fact that another command happens to be installed on the system.)
In order to actually change file permissions, you must first get an ACL object for the file system object in question, then modify it and set the ACL. The example at the link is fairly innocuous looking, but it is far more work than chmod & chown, and only gets worse as you want to do something nontrivial.
You cannot zip or unzip directly from the command line. If you run
you will get the Windows zip wizard to come up, the same as if you had invoked any other file that way, but there is no equivalent to:
that will just unzip the file, no questions asked. I have had it suggested, that the issue is one of licensing (namely, Microsoft’s licensing agreement for zip technologies does not permit them to create a commandlet with this functionality). This is certainly possible, but I, as a user do not really care. Of course, this being PowerShell, you could also write (as some already have) a commandlet that uses an external DLL like sharpzip to handle it. That is all well and good, but it would still mean that I have to manually copy PowerShell commandlets and DLLs to customers’ systems–something that is not usually possible.
Perhaps the most touted feature of PowerShell is the ability to dynamically load assemblies (DLLs) through reflection and expose the objects to the shell, making it especially useful in a standard BL-BO-DAL architecture when you have some setup tasks, to load your assembly and perform deployment tasks. On paper anyway. Unless–yes!–unless something goes wrong (we all knew it would go wrong, otherwise it would not have found its way into this post).
Like the fact that the latest version of PowerShell, v. 2.0, cannot load .NET 4.0 DLLs.
I guess that isn’t really fair. According to Microsoft it can’t. If you jimmy a couple of registry settings and pray that nothing bad befall you, it might work.
Ultimately, flaws like this are a natural offshoot of Microsoft’s traditionally anti-CLI culture. Since they almost single-handedly drive the philosophy of the ecosystem, the result is that few true Microsofties (as opposed to people who just happen to use Windows) understand CLI, so, when customers demand it (for systems administration a good shell installed by default is simply essential–we’ve been stuck with cmd for too long), there is no one who truly understands what they are supposed to be building.
Hopefully, Microsoft has been made aware of shortcomings like this and we can expect to see PowerShell refined into a truly pleasant shell. That has, after all, been Microsoft’s forte for years. Improving software to be what it should have been all along.