Introduction to Windows PowerShell

1 2 3 4 5 6 7 8 9 10 11 12 Page 3
Page 3 of 12

You could also type the following:

(dir c:\temp).delete()

which generates the same stream of File and Folder objects and calls the delete method on each object. The result is the same: The files are deleted.

(And, as you might expect, you could also just type remove-item c:\temp\*.*. That would be the most straightforward command, but it doesn’t show how PowerShell differs from the regular command prompt.)

Here’s another example of how a pipeline command can work:

dir | where-object {$_.LastWriteTime -lt <br>(get-date).addmonths(-6)} | remove-item

dir generates an object for each file in the current directory, where-object passes along only those that are more than six months old and remove-item deletes the old files. So, we’ve constructed a disk cleanup command out of general-purpose cmdlets. (Don’t type this command, by the way—it’s just an example!)

This is very peculiar and powerful, and it takes some getting used to.

An Extensible Environment

PowerShell can run three sorts of programs: built-in commands, external programs, and scripts. This is analogous to the regular Command Prompt environment, where you could use the built-in commands that are handled by the cmd.exe program itself, run external programs, or create batch files that let you orchestrate either type of command to perform the steps of a more complex task. In PowerShell, the built-in commands are cmdlets. Unlike the Command Prompt shell, however, these built-in commands are not wired into the PowerShell program but are added to it through a snap-in mechanism as one or more .DLL files stored on your hard disk. So, custom cmdlets can be added to the environment. The idea is that Microsoft and third parties can add install management cmdlets for their applications and servers, so that they can be managed by PowerShell scripts. Microsoft SQL Server, Microsoft Exchange, and VMWare servers have custom cmdlet snap-ins, for example. If you’re a skilled .NET programmer, you can create your own custom cmdlets using the Windows PowerShell 2.0 Software Development Kit (SDK) and Microsoft Visual Studio Express Edition, both of which you can download free from Microsoft.

In addition, PowerShell responds to command keywords that are part of its built-in script programming language which is a unique language, all its own. It’s not VBScript, it’s not VB.NET, it’s not C#. It’s PowerShell.

You can also create and use .NET and COM objects not just in scripts, as you do with WSH, but right at the PowerShell command prompt.

This means that every cmdlet, Windows program, command-line program, .NET object, and COM object (including WMI and ASDI) is available right at your fingertips.

Note - As an aside, it’s interesting to know that just as VBA provided an object-oriented, full-scale programming language that could be integrated into applications such as Microsoft Word, programmers can “host” PowerShell inside their .NET applications. PowerShell is intended not just for helping you automate your routine tasks, but to serve as the scripting/macro language for Windows applications and services.

Obtaining Windows PowerShell

Windows PowerShell 2.0 is installed by default on Windows 7 and Windows Server 2008 R2. For information on installing it on other versions of Windows, see PowerShell details on the Microsoft Web site.

The PowerShell Environment

You should be able to click Start, All Programs, Accessories and see Windows PowerShell as a choice (although you might have to scroll down; by default, it’s below System Tools). On 32-bit Windows versions, there are normally two choices:

  • Windows PowerShell—This is the interactive command-line environment. I discuss this first.
  • Windows PowerShell ISE—This is a GUI editing/debugging tool that you can use to help develop PowerShell scripts. I discuss this later.

On 64-bit versions of Windows, these two menu selections run the 64-bit version of Windows PowerShell. In addition, there are selections for Windows PowerShell (x86) and Windows PowerShell ISE (x86), which run the 32-bit versions of PowerShell. These are provided in case you have to use a cmdlet snap-in that is available only in a 32-bit version, but they are otherwise probably not of much interest.

Alternatively, you can open a regular Command Prompt window and type powershell or type powershell in the Windows Search box or Run dialog box.

Note - If you run PowerShell inside a regular Command Prompt window, you won’t get the default white-on-blue color scheme that you get when you open PowerShell from the menu, but it’s the same program. You can return to the regular cmd.exe command prompt by typing exit.

Windows PowerShell is subject to the same security issues as the regular Command Prompt. To modify system files or perform other administrative actions on Windows 7 and Vista, you must run PowerShell with elevated privileges. On Windows XP, to perform privileged tasks, you must be logged on as a Computer Administrator or run PowerShell under an Administrator account using runas.

I discuss this in more detail toward the end of this article in the section “PowerShell Security.”

Whichever method you use to start PowerShell, the next prompt you see should have the letters PS at the left, as shown in Figure 1 below. Type dir and press Enter, just to prove to yourself that this is not the old Command Prompt. The format of the directory listing is very different.

The PS to the left of the prompt tells you you’re using Windows PowerShell.

1 2 3 4 5 6 7 8 9 10 11 12 Page 3
Page 3 of 12
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon