PowerShell For Programmers: Basic Syntax — CMDLETs

PowerShell might look really strange to you. Many people assume PowerShell is basically CMD-prompt 2.0 because of the way it looks, but it really is a fully operational scripting language underneath.

PowerShell has something called a cmdlet (command-let), which for the most part is the same idea as functions you're used to from other languages.

I'll assume you're coming from a more classic language and you're used to calling functions like this:

MyFunction(Value, Value, Value)

If you've been using cmdlets in PowerShell like this, you've been doing it wrong. This could cause you some serious problems down the line.

"But I can type Get-Service("alg") and it works just fine!"

Probably, but that's just PowerShell doing some nice parsing tricks to help you. This will not work with every cmdlet or every parameter set (overload) of those cmdlets.

We should actually type something like: Get-Service -Name "Alg"

There are a lot of nice little tricks and shortcuts we can use to shorten lines as well, and I'll point some common ones out as we go.

Here are some basics you should know about cmdlets:

  • POWERSHELL IS NOT CASE SENSITIVE: Get-Command, get-command and GeT-CoMmaNd are the same
  • Cmdlets are always of the form Verb-Noun to help understand what they do without having to look at help data
  • PowerShell calls its arguments "Parameters"
  • Instead of just providing the parameter values in a specified order, we need to also provide the parameter name those values are going to. This makes them order-independent
  • Parameter names always start with a dash like -Name, -ComputerName, -Force
#these will work the same, despite the order difference
get-service -name "ALG" -ComputerName "localhost"
get-service -ComputerName "localhost" -name "ALG"
  • Some parameters have no value and are called switch parameters (like -force, -verbose, etc) these are settings that default to off and just typing -Force would switch them on.
#this will fail if notepad isn't open
stop-process -name notepad -whatif 
  • Some parameters are set to be "Positional", these let us eschew writing the parameter name (-ComputerName, -Name, -Whatever) and just provide the values. In this case the order matters, but you can always explicitly name them instead. I’ll show you how to identify these in the syntax later, but if you see people doing this, recognize that it is just a shortcut.
#these are the same
get-service -name "alg"
get-service "ALG"
  • Another common shortcut is that PowerShell can sometimes assume something you type is a string, even if you forget the quotes. A good rule of thumb is that you can assume a parameter expecting string data will let you skip the quotes (as long as you don’t have spaces or weird special characters). If PowerShell yells at you, just throw quotes on, but it explains why you usually see people type stuff like this:
#no quotes + positional parameter = short line 
get-service alg 
  • To see the syntax for a cmdlet you can use technet documentation or look in the shell using another cmdlet:
get-command -name "get-service" -Syntax
  • If you run this command on your own you will see multiple syntax blocks come back with distinct parameters. These are parameter sets, which you can think of as overloads.
  • To see more detailed info + examples + explanations of parameters we can use the help cmdlet. When using it, use the switch parameter -ShowWindow to make your life easier.
Get-help Get-Service -showWindow  


If you followed along with those points, then that is all you need to know about cmdlets.

  • Recognize that the long-hand is the way you should try to write most stuff for readability, but the shortcuts are common and valuable
  • If you are doing things like MyFunction(value,value) then you should stop and get on the correct syntax bandwagon to save yourself issues.

There are a couple other notes worth mentioning in regard to cmdlets and basic PowerShell syntax:

  • PowerShell contains Aliases that are alternate names for cmdlets. Many of these exist to make adoption of the language easier. They will either be anchored back to other shell commands (CMD, terminal, etc) or other programming language paradigms. Here are a couple common ones that you have probably used or seen used:
    • Things like Dir are well known from CMD, but Get-Childitem is unintuitive so they added the alias.
    • Aliases can take in the parameters the same way as their CMDLETs:
    • As a best practice, try to use full cmdlet names in your scripts because not everyone knows aliases. However, for certain ones like Dir, CD, etc it might be easier to understand than the real cmdlet. Use your best judgement.
    • If you ever see something that doesn't look like VERB-NOUN it is likely an alias, which you can look at with get-command or get-alias
#all do the same thing
Get-ChildItem -Path c:\
dir -Path c:\
ls -Path c:\
gci -Path c:\ 
get-command dir

CommandType     Name                                               Version    Source            
-----------     ----                                               -------    ------            
Alias           dir -> Get-ChildItem                                                            

  • External commands (all the old cmd stuff) like icacls, ipconfig, etc. all live on the PowerShell environment path. These spin up a new process when called, but you can use them in your script if needed. Try not to as they have way less standardized syntax than true cmdlets.

Well that’s all for now, hopefully this helps you get going on your PowerShell journey and clear up why you might see so many variations of the same command. I’ll be adding to the series to cover other quirks as well so let me know in the comments if there is any particular topics confusing you!

If you find this helpful don't forget to rate, comment and share 🙂

For the main series post, check back here.

Comments (10)

  1. Alex Wilson says:

    I have been a .net developer for 5 years and found this really useful. Looking forward to the next one.

    1. Kory T says:

      Glad you found it useful, I’m aiming to post every other week or so on this series, so check back on 1/18 for the next one 🙂

      1. Thanks for this amazing content.

        1. Kory T says:

          Thanks, glad you’re enjoying it!

  2. Seth Sams says:

    Nice job making this easy to digest. There are some good nuggets in this post!

    1. Kory T says:

      Thanks, glad you enjoyed it!

  3. André says:

    Thanks for the content! It was a pleasant reading.

    Also, I found a typo: “commond” in a sentence, just saying.

    Please, keep up the series.

    1. Kory T says:

      Glad you’re enjoying it, I fixed that typo, thanks!

  4. Arjun Bahree says:

    Good Informative for those coming from other langs and starting their PS journey.

    1. Kory T says:

      Thanks, glad you’re enjoying it 🙂

Skip to main content