Chapter 9. Avoiding bugs: start with a command

 

Before we ever fire up a script editor, we start in the basic PowerShell command-line window. This is your lowest common denominator for testing, and it’s a perfect way to make sure the commands your tool will run are correct. It’s way easier to debug or troubleshoot a single command from an interactive console than it is to debug an entire script. And by “a single command,” we mean a PowerShell expression—a single thing that we can manually type into the console to see if we’ve got the right syntax.

This is by design

One of the cool parts about PowerShell is that you can open a console, run commands, and get immediate results (or errors). Traditionally, programmers have had to write code as best they could, compile it, and possibly even code up a test harness so that they could test their code. Take advantage of PowerShell’s immediacy to reduce your overall workload!

9.1. What you need to run

If you’ve already read the previous chapter, then you know that in the example scenario, you’ve been asked to develop a tool that will query the following information-:

  • Computer host name
  • Manufacturer
  • Model
  • OS version and build number
  • Service pack version, if any
  • Installed RAM
  • Processor type
  • Processor socket count
  • Total core count
  • Free space on system drive (usually C: but not always)

9.2. Breaking it down, and running it right

9.3. Running commands and digging deeper

9.4. Process matters

9.5. Know what you need

9.6. Your turn