Overview
Recently, I was facing an issue that a variable had a different value than I expected. I was executing a script, let’s call it Script1, which was using a variable. Script1 was executing another script (let’s call it Script2). Script2 contained a variable with the same name. Once Script2 was done, the value in the variable from Script2 was still present in the variable of Script1. This short blog post will seek to unravel this mystery.
Preparation of a crime scene
Let’s start with the scene preparation. We are going to need two PowerShell scripts. These scripts are going to be stored in the same location.
Location:
- C:\TEMP
PowerShell Scripts:
- Script1.ps1 – this script is main execution script
- Script2.ps1 – execution of this script is invoked by Script1
Name of used variable:
- $myBelovedVariable
Script2 definition
We start with a code preparation for Script2. The script itself is very easy. It only has two commands:
- assign word “Craftsmen” into the variable
- write information into a console
- name of the script
- value in the variable
Script Code:
$myBelovedVarible $myBelovedVariable = 'Craftsmen' $MyInvocation.MyCommand.Name + ': ' + $myBelovedVariable
Script1 definition
Script1 will do almost the same as Script2 does. It assigns a value into the variable and then it executes Script2. The order of commands in Script1 is:
- assign word “Joyful” into the variable
- write information into a console
- name of the script
- value in the variable
- execution of Script2
- write information into the console
- name of the script
- value in the variable
Script code:
$myBelovedVarible $myBelovedVariable = 'Joyful' $MyInvocation.MyCommand.Name +': '+ $myBelovedVariable . C:\temp\Script2.ps1 $MyInvocation.MyCommand.Name +': '+ $myBelovedVariable
Scripts execution
The scene is prepared. Now, we can execute Script1.ps1 stored in C:\Temp. When we look more closely at Script1, without any deeper knowledge of PowerShell, we could then expect that value in the variable $myBelovedVariable should be “Joyful”. Let’s execute Script1.
If you did everything as is written above, then you’ve got an output as it is on the picture below. The variable in Script1 has the value “Craftsmen”. For some reason the value remains even after Script2 finished.
Oh wait. There is a dot on line 7 in the picture above. I’ll try to remove the dot and execute the script again. After execution, you can see in the picture below that our variable has value “Joyful”.
Outcome
As you can see in the execution part of the blog, there is something interesting in the life of a variable. As I pointed out, the difference is in the dot used for execution command. Usage of a “.” in the execution is called “Dot Sourcing” in the PowerShell. The difference between the two executions in the example is that:
- dot sourcing executes script in the current scope
- the second execution is not adding a script into the current scope
Final note that you should remember. When you dot source a script then all its variables and functions will persist when the script ends. If you do not remember this, then your scripts could work with unexpected value.
Source:
2 Comments. Leave new
Your figures seem backward from what you’re describing in the text: The dot/source command executes a file in the caller’s scope, not the lack of one. The dot command is line 4 in the second figure captioned “Script code”, not line 7 in “the picture above”, which invokes Script2 without a dot command. Or was your description misplaced?
Hi Ed,
thank you very much. I’ve accidentally added figure in wrong order. It is in correct order right now.
Regards,
Oli 🙂