Top Ten: PowerShell Annoyances

After leaving Windows PowerShell on the shelf for a few months, I recently had to rework some of my existing scripts for some benchmark tests I was performing for one of our product reviews. I've always been a fan of PowerShell, but in the process of working with these scripts, I couldn't help but notice (i.e., be annoyed by) some of the different PowerShell "features" that are certain to confuse administrators and others who are trying to learn PowerShell. I'm aware that there are reasons for all of these different features. However, they're almost all hurdles to learning PowerShell, and many could make people throw up their hands and give up, which would be unfortunate because PowerShell is on the verge of becoming a necessary tool for the Windows administrator. In this column, I'll share the top 10 things that annoy me about PowerShell.

1. Positioning PowerShell as an interactive command console—Maybe it's because I jump in and out of PowerShell according to the tasks I want to accomplish, but I almost never use PowerShell straight from the PowerShell command line. Microsoft uses automation and productivity to sell PowerShell, and you don't get those things by attempting to type in a bunch of complex text commands. You get automation and productivity by running scripts that automate repetitive tasks.

2. Default execution policy prevents scripts from running—I realize this feature is there to secure your scripts, but there's no doubt that just about every PowerShell newbie is going to run into the default Restricted execution policy right out of the gate, which prevents scripts from running. And you'll probably hit this problem again on each and every new system where you want to run your scripts. Remember, if you want to run a script, you first need to run Set-ExecutionPolicy RemoteSigned or Set-ExecutionPolicy Unrestricted.

3. Not being able to run PowerShell scripts from the command line—No wonder Microsoft likes to promote PowerShell as an interactive environment. Even in the PowerShell environment, you can't run a script just by using its name. From the Windows Command Shell, you can't run a PowerShell script just by entering its name at the command prompt. If you're running a Windows Shell, you need to use powershell -noexit "& "C:usersmikeomy scriptPSscript.ps1" to launch a script, which leads directly to my next annoyance.

4. Calling PowerShell scripts—It's not enough that you can't start a PowerShell script by typing its name. You can’t even easily start it by passing it as a parameter to the powershell.exe executable if the path name has any spaces in it. Instead, you have to add the call operator, &. Adding the & isn't exactly intuitive, and it's definitely a hurdle for beginners.

5. Not being able to run scripts out of the current directory without an explicit reference—Another annoyance occurs when you attempt to launch scripts out of the current directory. Unlike the friendlier Windows Command Shell, PowerShell doesn't load commands from the current directory by default. You must either explicitly supply the path, which is a tedious and error-prone process with today’s long path names, or you can use the . notation, for example: ".. If the path name contains blank spaces, you need to enclose it in double quote marks.6. The need to load cmdlets—The need to load cmdlets is especially a problem in the many PowerShell example scripts that you see for the different server products. They almost always assume you've already loaded the necessary cmdlets to interact with the server product, when in fact you’ve probably just opened PowerShell and are attempting to run their scripts. The example scripts for different server products won't run until you've loaded the product-specific cmdlets, and you might not know what’s wrong, depending on your level of experience with PowerShell.7. Cryptic error messages—Cryptic error messages are a problem with almost all software these days, and PowerShell is no exception, with its bright red error messages that you’re sure to see frequently when you're new to PowerShell. To reduce these errors, be sure to make use of the PowerShell error-handling statements in your scripts: Trap, Try/Catch/Finally, and Throw.8. Difficult syntax—Most of PowerShell's syntax is pretty good. Its verb-noun syntax is easy to follow, and prefacing variables with the $ is also easy. However, it’s not all so straightforward. For instance there’s the $_, which is often used in loops to represent the current value and can also be used to filter pipeline results. Then when you combine that symbol with brackets and the dot, for example, {$_.}, you’ve lost most non-developers. I know that there's nothing to be done about this problem, but I don't find it intuitive.9. Weak Integrated Scripting Environment (ISE)—Yes, PowerShell's ISE is better than Notepad. Yes, it can edit, run, and debug PowerShell scripts. However, it's also the low-end of PowerShell development tools, and I must admit I would expect more from Microsoft. After all, Microsoft is famous for its development tools. Hopefully, Microsoft will do some work on the ISE with Windows Server 2012, but until then, if you're serious about working with PowerShell, look into PowerWF, PrimalScript, Admin Script Editor, or maybe PowerGUI.10. Getting Help—For more PowerShell information, start with the built-in PowerShell Help cmdlet. But honestly, reading those text screens isn’t easy. For Windows Server 2012, you can check out Windows PowerShell Support for Windows Server 2012. You might also want to watch some of the PowerShell webcasts like, PowerShell Essentials for the Busy Admin at Scripting with Windows PowerShell.