Understanding PowerShell Terminology

Posted on May 17, 2016 by Jeff Hicks in PowerShell with


When you are first learning PowerShell, there are often a number of terms and words that everyone assumes you know. Well let’s not make that assumption. Instead, let me at offer at least a quick definition for much of the PowerShell terminology you will encounter. You should know how to use the help system to get additional information on these terms, but sometimes you need a little background to either know where to start looking or to put things in perspective. This is by no means an exhaustive list, but rather items based on my experience presenting PowerShell at conferences and in private training classes.


A cmdlet, pronounced “command-let” is PowerShell’s core unit of execution. Think of it as a little command that you run to do something. Not that it should matter to you, but a cmdlet is a compiled program written in a .NET language, usually C#. These programs follow a naming convention of Verb-Noun, which makes them easy to understand. The verb comes from a standard set of verbs, which you can see by running Get-Verb at a PowerShell prompt. The noun is a singular version of the object or thing that you want to work with. This makes it pretty easy to understand what a command like Get-Eventlog is going to do. You can get a list of all available cmdlets by running Get-Command.


An alias is an alternate name for a PowerShell command. The command might be a cmdlet, a PowerShell function or even a Windows application. You can create your own aliases with the New-Alias cmdlet. Aliases are intended to simplify the amount of typing in the PowerShell console. Instead of having to type Get-Service, you could type gsv in its place. While using aliases in an interactive session can streamline your work, the recommended best practice is not to include aliases in your PowerShell scripts as an alias can often be cryptic whereas the full cmdlet name like Get-Service is much clearer.

Aliases often serve as transition aids as well. For example, a Linux admin coming to PowerShell might not know about the Get-Process cmdlet, but they are using it to running the ps command. In PowerShell, this is an alias to Get-Process. But it is important to remember that ps is not the Linux ps command, only an alternate name. The Linux admin would eventually need to learn the syntax for Get-Process, although they could continue to use ps. If you aren’t sure what an alias is you can use help on the alias, or run the Get-Alias cmdlet.


Think of a variable as a placeholder for something else. A variable has a name like Computername, but when referenced or accessed in PowerShell you need to preface it with a $ sign. Variables make it easy to reference values that might change like a number.

You can now use the variable $i in any PowerShell expression.

You can change the value of $i and then re-run the command. Variables can also hold the results of a command.

The variable S holds the output of the Get-Service expression, which will be all of the running services. You can access the contents of $s any time you want and use them however you want, just as if you had run the Get-Service expression. Although the variable is a point-in-time. If the status of a service changes, you won’t see the change in the $s variable.


A provider (sometimes referred to as a psprovider) is a part of PowerShell that makes it possible to access different systems with essentially the same commands. Think of the provider as an interface between PowerShell and a part of Windows like the file system and the registry. The provider is a bit of software that translates a cmdlet to be used with the underlying system. For example, PowerShell has providers for the file system and the local registry. You can use the same cmdlets like Set-Location or Get-Childitem to navigate the file system and the registry. The provider does the work of translating the command. The benefit for you is that once you know how to navigate the file system, you can use the same commands to navigate the registry.

You can see a list of available providers with the Get-PSProvider cmdlet. Depending on what modules you have loaded, you might see additional providers. The providers give access to their respective areas through a PSDrive. You use PSDrives all the time when navigating the file system. The Get-PSDrive cmdlet will display all of your current drives. Many of these are automatically created and of course you can create your own.



The PowerShell pipeline is perhaps the most important term and concept. The idea of a command pipeline is not unique or new to PowerShell. The pipeline connection is depicted with | symbol. The pipeline is a construct that allows PowerShell to pass objects from one command, usually cmdlets or functions, to another and another until you are finished. The command must be designed to accept pipelined input, which many PowerShell commands are. At the end of the pipeline PowerShell will display any objects remaining.  One of the interesting aspects of the PowerShell pipeline is that you might start with one type of object at the beginning of the pipeline but PowerShell writes a completely different object at the end. For example, you might have a pipelined expression like this:

At the beginning Get-Process is writing a process object to the pipeline but at the end PowerShell is writing a GenericMeasureInfo object. Personally, I find working with the pipeline the most rewarding part of PowerShell because you can achieve amazing results with minimal work. And if you’ve ever worked with VBScript you’ll be amazed at what you can accomplish without any type of scripting.


A PowerShell script is a text file with a .ps1 file extension that will be executed much like old-fashioned batch files. A script is nothing more than a series of PowerShell commands stored in a text file. When run, PowerShell executes all of the command in order. Thus there really is no difference between running commands interactively in the shell and running them in a script. Often you can take commands from a script file, copy and paste them into to a console session and PowerShell will run them. I tend to think of a script as a “canned” PowerShell session. Although we use script files to define functions and as part of modules.


A function is a modular piece of PowerShell code designed to do one thing. You should think of a function as a script version of a cmdlet. In other words, you can create your own commands in PowerShell script without having to program in Visual Studio.  Functions can be very simple or as complex as a cmdlet where they can accept pipelined input, have parameter validation, include help and much more. When you are first learning to script in PowerShell it is fine to begin with simple and basic functions. Over time you can extend them and eventually create some very powerful tools.


A module is a PowerShell package of related commands. Microsoft ships many of the commands you use everyday as part of several different modules. You can use the Get-Module cmdlet to see what modules are currently loaded as well as what is available. You used to have to import a module before you could use any of its commands. But now PowerShell will automatically import the module the first time you use one of its commands. As long as you know the command you want to run, you don’t need to pay much attention to modules. Eventually, you will learn how to create your own modules, which are nothing more than a collection of PowerShell script files, and distribute them.


A snapin, or pssnapin, is another type of command packaging. In the early days of PowerShell this is how additional commands were delivered. A snapin was packaged in such a way that it needed to be installed and registered on your computer before you could use it.  You can use the Get-PSSnapin command to display loaded and registered snapins. Today, most PowerShell extensions are delivered via modules so you won’t see this much any more.


I’m sure there are plenty of other terms that merit definition but these should be the most common ones and be enough to get your started. You should be able to use the Help system to learn more and of course there is plenty of PowerShell content right here.

Tagged with

Register for this upcoming webinar on Petri.com
Webinar: Accelerate Smart Factory ROI with Deloitte and HPE’s Digital IoT

Join HPE and Deloitte for a discussion on how to take advantage of IT and OT convergence to deliver the Factory of the Future

Tuesday, October 24, 2017
at 2 p.m. EST

Register for this upcoming webinar on Petri.com
Webinar: Accelerate Smart Factory ROI with Deloitte and HPE’s Digital IoT

Join HPE and Deloitte for a discussion on how to take advantage of IT and OT convergence to deliver the Factory of the Future

Tuesday, October 24, 2017
at 2 p.m. EST