Summary: Microsoft Scripting Guy Ed Wilson talks about using different types of commands in Windows PowerShell. Microsoft Scripting Guy, Ed Wilson, is here. A while ago, someone said there must be 50 ways to stop a process in Windows PowerShell. Although I am not certain that number is entirely accurate, it probably comes close. The great thing about all the different ways of doing things in Windows PowerShell is that it permits us to meet Windows PowerShell from our current backgrounds. This enables us to leverage as much previous knowledge as possible. For example, suppose you spent years as a .NET developer, and you are very knowledgeable about .NET development. When you learn that Windows PowerShell is built on .NET, is basically a .NET application, and uses .NET in the background, you can begin to use your prior knowledge to quickly begin writing Windows PowerShell script. For example, to get the current date, I can use the now static property from the System.DateTime object. It would look like this:

[datetime]::now In addition, when I learn that Windows PowerShell also returns objects, I can capture that returned System.DateTime object in a variable and perform date manipulation by using standard .NET methods from the DateTime class. That is all good. But eventually, you may want to learn that you can just as easily obtain the current date and time (as a DateTime object) by using the Get-Date cmdlet. And that is part of the point. You do not have to learn everything about Windows PowerShell immediately. You can use whatever previous knowledge you have. Then if you want to update to using “native PowerShell ,” you can as you have time. The whole thing about Windows PowerShell is to make the job easier. It is not that Microsoft is “forcing me to learn Windows PowerShell,” but rather that I want to use Windows PowerShell because it will make the job easier. Like everything, there is a learning curve that you need to go through. Let’s think about the process of removing a bolt. There are lots of tools that can do this. I can use a crescent wrench, and it will remove lots of different size bolts. But of course, the crescent wrench is not really the best tool for the job because it has a tendency to slip and to round over edges. Maybe the next tool to consider would be a combination wrench. Now here is a learning curve. I need to be able to pick out exactly the right wrench. No longer can I sort of get it right—I need to be precise. In addition, there are two ends on the combination wrench, and I need to learn what each end is good for. When I make it past this learning curve, I can start to do a better job of removing bolts. But then someone comes along with a ratchet and socket system. There are multiple sizes of ratchets and hundreds of sockets, extensions, swivels, and even breaker bars. Dude, talk about a learning curve. I just went from one crescent wrench, to 13 combination wrenches, to hundreds of pieces in the socket set. Now my boss comes along and says he has a couple of air ratchets and an impact wrench. Now we have air compressors, hoses, fittings, oil for wrenches (some of which are oil-less). Dude, the list goes on. But each new tool brings me further up-the-line in terms of precision and automation. One problem with so many different ways to do something is that it can complicate learning among people who are just beginning. So it is with learning Windows PowerShell. When new learners find three different examples, all purporting to show how to do something, and all three examples show completely different things, it can be confusing. But it can also be useful because I now have three ways of doing something, and I can simply choose the one that makes sense for me. The challenge is to move beyond copying examples so you can discover how and why the examples actually work. There are those who try to be “pure Windows PowerShell” and who try to only use the “PowerShell way” of doing things. Surprisingly, maybe the Scripting Wife falls into this category. For her, the decision was to learn the “PowerShell way” of doing things and to avoid confusion that may crop up by doing things the .NET way, the WMI way, or the VBScript way. It makes sense to an extent. For me, I simply prefer the easiest way of doing things. For me, easiest actually translates to the first thing I think of to solve my problem. In this manner, I am not a Windows PowerShell purist. I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace. Ed Wilson, Microsoft Scripting Guy