PowerShell Debugging: You can change variables but don’t shoot yourself in the foot!

• PowerShell Studio
• Scripting
• Windows PowerShell

Warning: This article is heavily laced with pop culture references and general silliness.

The PowerShell Studio v5.6.161 service release allows you to modify variables in the Variables and Watch panels when you are at a breakpoint. Many of you have requested the ability to change variables during debugging, and since we like you and you support us by purchasing our software, we obliged.

Now let me channel my inner Uncle Ben:

With great power comes great responsibility! Excelsior!
                                                            – Uncle Ben (and Stan Lee?!)

Oops! It seems like I channeled the late great Stan Lee too! Regardless, this famous Spider-Man quote applies to PowerShell debugging and to scripting in general. PowerShell gives you a lot of control over your scripts and your environment. When we are given this “power”, it is easy to take for granted and to abuse.

Modifying Variables

To modify a variable, start the debugger and hit a breakpoint.

Then there are one, two, five.

     Three sir!

Three! Three ways you can modify variable values:

1. Variables Panel:

Simply click on the value field, and the cell will allow you to edit the value:

2. Watch Panel:

You can use the Watch panel to edit a variable you are watching.

I always feel like, somebody’s watching me!

                                          – Rockwell – Somebody’s Watching Me.

Click on the value cell and set the new value:

Note: The watch expression must be a variable; otherwise you will not be able to edit the value.

3. Debug Console:

Use the Debug Console to make a simple assignment:

Or use the Set-Variable cmdlet:

Another Tool in the Toolbox

Modifying the variables can be a useful debugging tool when trying to figure out where your script is failing, but it can have unintended consequences if you aren’t mindful of what you are doing.

Be one with the script, Luke.
– Obi-Wan Kenobi

Yes, Obi-Wan totally said that in one of the early drafts of the Star Wars movie when Obi-Wan was teaching Luke the way of the Dev-Op. Unfortunately, it didn’t make it into the final movie. A real bummer. George Lucas really dropped the ball on that one.

Now, back to changing variables and debugging. You are a professional using a professional tool. Because of this, we have placed no restrictions on this new functionality. So:

Don’t shoot yourself in the foot!!
– Me

Who, me?
Yes, you!
What do you mean? I don’t make mistakes!
Yes you do, and I do too!

Making mistakes is nothing to be ashamed about. In fact, we learn from our mistakes. Use your past mistakes to build a firm foundation of knowledge onto which you can grow and achieve better things! And eventually (hopefully!) succeed.
You would be surprised how often successful people have failed. We tend to focus more on the successes than the failures when it comes to others (e.g., founders). The important message here is to have grit* and to learn from your mistakes. It is ok to fail, but don’t fail because you didn’t try or you put little effort into it. Be mindful and give it your all!

* Grit: courage and resolve; strength of character.

Now let me give you an example of how changing variables without mindfulness can result in errors within your script. The output from the GUI script is displayed incorrectly in a textbox:

Now I hit a breakpoint and decide to update the textBox1 variable. I want to change the text that is displayed by the control, so I go to my Variables panel and set the new value:

Wait! Did you catch the mistake? Now I continue to run my script and get errors galore!

Instead of changing the Text property of the TextBox control, I replaced the control’s variable with a string object.

Note: This is a common mistake to make when you don’t understand how the GUI control works. There is no shame in that.

Now my script is broken. Luckily this is a sample script that is messing with production servers!

If I were to use my powers of time travel, I would say to my past-self:

Stop! Don’t do that! Instead set the Text property, you handsome fool!

After realizing my D’oh moment, I would then expand the textBox1 variable and set the Text property in the Variables panel:

Now my imaginary disaster is averted and my foot is safe!  Except for maybe causing a small tear in the space-time continuum. Eh. Who’s going to notice?

To sum it up:

We have given you the power and the associated responsibility to modify variables while debugging, which in turn makes it easier for you to shoot yourself in the foot. I’m pretty sure you like your proverbial foot, so be sure to look before you shoot!

• Next