Subshells (by the Seashore?)

Yesterday’s post detailed some frustration I encountered running PowerShell in a subshell.  Why was I running it in a subshell in the first place?

I’m glad you asked.

It all started a long time ago (well, a few years, but it felt like a long time.)  I was developing my script the way many of us do: copy-and-pasting code from the script editor into the test window.  As it got closer and closer to done, I started save-and-executing the file. All’s fine and dandy, except I failed to define a variable in the script itself.  However, I did define it in my test window.  When I ran the script, PowerShell’s scoping rules allowed the script to pluck the variable from the PowerShell.exe shell, and the script worked.

Until it didn’t, which was when I was demoing it.

Since then, I’ve always run my script testing PowerShell windows in a subshell.  Upon creating the window I type

function prompt { “cmd /c powershell.exe –noprofile`n” }

That’s the test window’s root shell’s prompt.  It reminds me that I’m at the bottom of the barrel, and one more ‘exit’ will close the window.  Then, to start a shell, I run:

cmd /c powershell.exe

Yes, I suppose I could simply call PowerShell.exe –NoProfile, but there’s something reassuring about dropping to cmd.exe so there is no way the Variable: PSProvider can follow me around (or Function:, Alias:, etc.)

Comments (0)

Skip to main content