imageOne of the great things about PowerShell is the language is designed to be read and easy to understand.  PowerShell does not use some esoteric lingo or new words to describe the objects you work with in the shell, it uses common language and terms.  For instance when you look at this PowerShell example:

Get-Service (btw this is officially known as a cmdlet pronounced “command-let”)

or this example:

Get-Service -Name NetLogon -RequiredServices

The results of these commands provide are pretty straight forward, the first example will show you the services on the system and the second will show you the required services for the NetLogon service.  Let me break this down even further, all PowerShell commands can be broken up into even smaller components.  Much like we break down a sentence in any language to verb (action), noun (object), or adjective (descriptions) we can break PowerShell down into this common syntax as well.  When you take a closer look at the second example (Get-Service -Name NetLogon –RequiredServices) you should be able to see the components:

Get = Verb

Service = Noun (Objects)

-Name = Adjective (officially known as a parameter)

So just like a sentence you perform actions with your objects, and if you need more specifics you can add parameters to learn more, organize output or filter the results.  All of your commands will follow this base structure and these commands are all highly “reverse engineer-able”.  For example in the second example, you saw how to find the required services for the NetLogon service, what if you wanted to learn the required services for another service, simple just replace the name of the service.  This is an important basic principle  for all PowerShell scripts and commands.  Additionally the great thing about the majority of the verbs in PowerShell is that they are common across the various different objects you will work with.  Most of the verbs functions are obvious, start, stop, recover, write, remove…etc.  Most of the nouns/objects are in common terms as well, service, process, ADobject..etc.   One of the more common verbs you will use is Get.  This verb is the general all purpose informational verb, you want to learn about services or process it will start with Get.  In the next post, I will talk more about how to get all the commands available in your PowerShell session, btw the command you would use is hidden in the sentence. 

There are a couple of fun facts about the PowerShell language.  First almost all of the objects used in your PowerShell commands are singular, it is Service not Services, Process not Processes..etc.  I say almost with 99.9999% reliability.  I used to say 100% then I ran into some of the Group Policy PowerShell objects which just happen to end with a “s”.  While it is a bummer, I let it slide because I love Group Policy and quite frankly it rocks!  As you begin to learn to use PowerShell for your unique reasons you will quickly become familiar with the objects and parameters used to work with those objects, and you can avoid a lot of bad command type errors by simply dropping the “s”.

The second fun fact is how sensitive PowerShell as a language can be.  PowerShell is a sensitive language, it is most definitely , spelling and syntax sensitive.  PowerShell has very little tolerance for misspelled words in your commands or the overuse of commas, just like editors for a book.   (BTW, thanks go to Tome for catching some of my errors in the first post). With that said,  PowerShell as a language is mostly:

CAsE InSeNsITiVe

So when you are writing your cmdlets and scripts keep that in mind. When you are looking at help files or other forms on online documentation, it will follow a mixed case pattern with the beginning of every word in the cmdlet being capitalized. According to the documentation you would see the get-service cmdlet written officially  like this: Get-Service.  However, all three variations of this cmdlet will do exactly the same thing:

  • get-service
  • GEt-sErVIce
  • GET-SERVICE

Whether you type the cmdlet in all lower case, this is usually how I write my cmdlets, or if you write your cmdlets with a mix of case, or if you write your cmdlets in ALL UPPER-CASE, they will all do the same thing.  Of course if you do write in UPPER CASE, PowerShell 2.0 will think you are yelling at it.  Do not worry you cannot hurt PowerShell 2.0 feelings. PowerShell 2.0 will take it in stride, and still deliver your results. Of course that is if you spelled things correctly and had proper syntax.  However, I do offer one word of warning, when you find yourself typing in all UPPER CASE, I would caution you not to pound the keyboard, you can possibly hurt the keyboard or get keyboard finger(it is like turf toe, you can  look it up). When that happens to me, it is usually an indication to go for a run, lift some weights, or hit something really hard, in short step away from the keyboard.  BTW I do not recommend golf, that could make matters worse. :-)

You may have also noticed, we changed the title of the series posts I like this new title, but if you prefer the old title “PowerShell Not your Father’s Command Line “, email us and let us know.  Also remember if there is a topic on PowerShell you are curious about and would like Sarah or myself to cover in these postings, all you need to do is ask. Email either of us with your comments or suggestions, we look forward to hearing from you.  Have a great day!