PowerShell Best Practices for the Console

PowerShell Best Practices for the Console

  • Comments 9
  • Likes

Summary: Microsoft Scripting Guy, Ed Wilson, talks about Windows PowerShell best practices for the console.

Microsoft Scripting Guy, Ed Wilson, is here. This morning, the Scripting Wife and I decided to head to a new breakfast place that had great reviews on Yelp. We grabbed our Surface 2s and headed into town. Teresa had her new Surface 2 RT with 4G, and I took my new Surface 2 Pro with the power keyboard.

One of the things that got my attention about this restaurant was the statement that they made their scones in house from fresh ingredients instead of from mixes. They also claimed to have 30 different types of tea, so I was in.

Well, they did have scones, but most were covered with ½ inch thick sugar icing. I did find a multiberry one that was not. Most of the teas were fruit or herb, which I am sure you know is not even a real tea. But I did settle on a nice cup of English Breakfast tea. They had a good Internet connection, so our breakfast was worthwhile.

Speaking of worthwhile…

I spend most of my day with the Windows PowerShell console. In fact, I generally have two Windows PowerShell consoles open at the same time. I have one in which I am working, and a second one where I am looking up Help content. If I need elevated permissions, I open a third Windows PowerShell console.

Remember the purpose

The key thing to remember is the purpose of the operation. For example, when I am working interactively at the Windows PowerShell console, I am focusing on commands and quickly getting work done. Here are some of the things that I do:

  1. I turn on the Windows PowerShell transcript: Start-Transcript.
  2. I do not use Set-StrictMode.
  3. I use aliases as much as I possibly can.
  4. I use Tab expansion where I cannot use an alias.
  5. I make extensive use of the history: Get-Command –noun history.
  6. I make extensive use of my Windows PowerShell profile.
  7. If a command goes to more than two lines, I move it to the Windows PowerShell ISE, and format it so it is easier to read.
  8. I use positional parameters.
  9. I tend to use rather non-complicated syntax.
  10. I do a lot of grouping, and I select properties from returned collections.
  11. I explore Help for cmdlets and examples in my other Windows PowerShell console. Often I experiment with modifying Help examples.
  12. I use type accelerators when appropriate, but I prefer to use standard Windows PowerShell cmdlets.
  13. I am not shy about using standard command-line utilities inside the Windows PowerShell console if no easy Windows PowerShell equivalent exists.
  14. I like to use Out-Gridview to help me visualize data and to help explore data relationships.
  15. I prefer to store returned objects in variables, and then sort, filter, and group the data. In this way, I only have to obtain the data once.
  16. I like to set $PSDefaultParameterValues for cmdlets that I always use in a standard way.
  17. I like to store my credentials in a variable. I use Get-Credential early in my Windows PowerShell session, and then I can reuse the credentials. I typically use a variable named $cred so it is easy for me to remember.
  18. I like to create a list of the remote computers I am going to use early in my Windows PowerShell session. Typically, I use the Get-ADComputer cmdlet and filter out what I do not need.
  19. I like to create remote Windows PowerShell sessions to my target computers early in my Windows PowerShell session. I store the sessions in a variable I typically call $session. Most of the time this is a CimSession, but occasionally it is a normal remote Windows PowerShell session.
  20. In my Windows PowerShell profile, I create aliases for the cmdlets I use on a regular basis. My list is now around 20 aliases.
  21. I create several Windows PowerShell drives (PSDrives) in my profile. I like to have a PSDrive for my module location and one for my script library.
  22. I parse my environmental variable so it is easy for me to access resources such as my document library, music library, and photo library. I store the paths in appropriate variables, so I can use $doc instead of C:\Users\ed\Documents\.
  23. I use PSReadline.

That is a quick overview of best practices for working with the Windows PowerShell console. Best Practices Week will continue tomorrow when I will talk about best practices for Windows PowerShell scripts. What are some of the things that you do to make life easier when you are working in the Windows PowerShell console?

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 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Dont forget: Use filter instead of where so you dont load more than necessary.

  • PSConsole which is mentioned at the end is great. But for those who familiar with Far Manager I would also recommend to take a look at FarNet.PowerShellFar (see NuGet) which implements the console based ISE in Far Manager. Here is the very short list of features: https://github.com/nightroman/FarNet-Wiki/wiki/PowerShellFar-features (starred by Scott Hanselman, if this matters). Unlike various GUI ISE's, this ISE does not have difficulties with invoking native applications, even with interaction, because the host is implemented for a genuine console environment (thanks to Far Manager features and API exposed via FarNet).

  • Is there a reason to use the Console over the ISE? I see this often but never understood why, is it Start-Transcript?

  • @Anon, command-line (console) apps may not work in ISE as they do in console.

  • thank you