Have you ever tracked down a bug, been confident that you had found the root of your problems, only to realize shortly afterwords that you missed it completely?
What I posted yesterday as a bug in PowerShell (having to do with recursive functions, dot-sourcing, and parameters) seemed during my debugging session to clearly be a bug. After all, I watched the parameter value change from b to a, didn’t I? Sure did. And in almost every language I’ve ever used, that would be a bug. On the other hand, PowerShell is the only language that I know of that has dot-sourcing. Here’s a much simpler code example which shows my faulty thinking:
function f($x){
if ($x -eq 1){
write-host $x
. f ($x+1)
write-host $x
}
}
f 1
Here, we have a simple “recursive function” which uses dot-sourcing to call itself. In my mind, how this would have worked is as follows:
- We call the function, passing 1 for $x
- The if condition is true, so it prints 1 and calls the function, passing 2 for $x
- In the inner call, the if condition is false, so nothing happens
- We pop back to the calling frame, where $x is 1 and print it
If it weren’t for that pesky dot operator, that would have been accurate.
The problem is, the dot operator changes the scoping of the inner call. Here’s what the about_operators help topic, has to say about the dot sourcing operator:
Description: Runs a script so that the items in the script are part of the calling scope.
Which is not a surprise…really. The reason I was using the dot operator in my package management code was to make sure that functions defined in the scripts it was calling would be included in the existing scope, rather than their script scope. The problem was one of nearsightedness. I was so focused on the fact that the dot sourcing was making the functions part of the caller’s scope that I didn’t consider that variable declarations (including parameters) would also be in the caller’s scope.
So, the correct interpretation of the above script is:
- We call the function, passing 1 for $x
- The if condition is true, so it prints 1 and calls the function, passing 2 for $x
- The parameter is named $x, so $x in is set to 2 (overwriting the $x that was set to 1)
- In the inner call, the if condition is false, so nothing happens
- We pop back to the calling frame, where $x is 2 and print 2.
The trick here is that the function f dot-sourced something that set $x to 2. The fact that it was f is incidental. It didn’t have to be.
Maybe this example will make it more clear:
function f($x){
write-host $x
. g
write-host $x
}
function g{
$x = "Hello, World!"
}
f 1
If we were doing this without dot-sourcing, we would expect to see the number 1 printed out twice. However, since we dot-sourced g, the assignment in the function body of g happens in the scope of f. In other words, it’s as if the $x=”Hello, World!” were executed inside f. Thus, the output of this script is 1, followed by “Hello, World!”.
So, it wasn’t a bug, it was just me not being thorough in applying my understanding of dot-sourcing.
Now, on with Package Management.
First, to fix the problem caused by the parameter being overwritten (which it is, it’s just that it’s expected to be). I hadn’t worked out a way to fix the problem before I went to bed last night, but as I was rolling this stuff around in my head (which is when I figured out that it wasn’t really a bug), I thought of a simple solution. Since we can expect that sometimes the $filename parameter in the require (and reload) function will be overwritten by the a value in the dot-sourced script, we just need to make sure we’re done using it at that point. So, I simply made the assignment to the dictionary before dot-sourcing. Here’s the updated code:
$global:loaded_scripts=@{pkg_utils='INITIAL'}
function require($filename){
if (!$global:loaded_scripts[$filename]){
$global:loaded_scripts[$filename]=get-date
. scripts:\$filename.ps1
}
}
function reload($filename){
$global:loaded_scripts[$filename]=get-date
. scripts:\$filename.ps1
}
To add modules, we need to do a few extra things:
- We need to detect if we’re running in 2.0 or not
- We need to see if there is a module with the given name
- We need to see if the module is already loaded or not (in the case of require…it won’t matter for reload
Fortunately, none of those are very difficult. Here’s the updated code (including modules). I even added some comments to make the flow more clear:
$global:loaded_scripts=@{pkg_utils='INITIAL'}
function require($filename){
if ($global:loaded_scripts[$filename]){
# this function has already loaded this (script or module)
return
}
if ($psversiontable){
# we're in 2.0
if (get-module $filename -listavailable){
#the module exists in the module path
$global:loaded_scripts[$filename]=get-date
import-module $filename
return
}
}
#it wasn't a module...so dot-source the script
$global:loaded_scripts[$filename]=get-date
. scripts:\$filename.ps1
}
function reload($filename){
if ($psversiontable){
# we're in 2.0
if (get-module $filename -listavailable){
#the module exists in the module path
$global:loaded_scripts[$filename]=get-date
import-module $filename
return
}
}
# it wasn't a module...so dot-source the script.
$global:loaded_scripts[$filename]=get-date
. scripts:\$filename.ps1
}
That’s it for today. Let me know what you think.
-Mike
) the line of code that merges the error stream into the output stream (so that errors we throw with our new cmdlets will show up in the console). We’ll still need to update the our PSHostUserInterface class to handle the WriteError method, but that’s pretty easy (as are the debug, verbose, and warning methods):
