I often do things, or learn things, in PowerShell that lead me in the direction of writing a new post. Sometimes it’s just experimenting, and sometimes it’s a part of a bigger project. Well, the latter is why we are here today. A current profile script project of mine — that I’ll post as soon as possible — requires that a new ConsoleHost (that’s the standard blue console screen; not the ISE), open and then the current one close. That part is easy.
The problem is that my new ConsoleHost needs to know if a variable has been set, or not, in the previous ConsoleHost. Here, follow along. Start by opening a new ConsoleHost. Inside that host program, create a variable and assign it some sort of value, as I’ve done in the below example.
PS > $Variable = 'This is my standard variable.' PS > $Variable This is my standard variable.
In my above example, I tested that my variable had been properly assigned by returning its value. So far, so good. Now, we’ll run a command to (1) open a ConsoleHost from this ConsoleHost, and (2) exit the original ConsoleHost. The semi-colon is a command separator. It allows me to put two commands on the same line and have them run in succession with a single press of the Enter key. One ConsoleHost closes and a new one opens.
PS > Start-Process -FilePath powershell.exe; exit
Now that we have a new ConsoleHost and our old one has exited, let’s see if our variable is waiting for us.
PS > $Variable PS >
Nope. That variable was created in a different PowerShell session, and so there’s no getting it back. It simply doesn’t exist any longer. Without fully thinking it through, I briefly thought to use a globally scoped variable instead. It wasn’t long at all, before I realized what a foolish idea that had been. My ConsoleHost was the global scope. With another ConsoleHost, all I’d have is another, separate global scope. Not helpful. I considered writing the variable to disk, but luckily, I didn’t have to consider that option for long either. I had a better idea; I was going to use an environmental variable. Follow along.
PS > $env:Variable = 'This is my standard, environmental variable.' PS > $env:Variable This is my standard, environmental variable. PS > Start-Process -FilePath powershell.exe; exit
Windows PowerShell Copyright (C) 2016 Microsoft Corporation. All rights reserved. PS > # This is a new PowerShell ConsoleHost. PS > $env:Variable This is my standard, environmental variable. PS > ise
PS > # This is in the PowerShell ISE Host. PS > $env:Variable This is my standard, environmental variable.
So, as we’ve seen, the environmental variable will follow us along from ConsoleHost to ConsoleHost to the ISE too, providing we open each of them from an existing host that includes the environment variable. Oh, and if you were wondering, the variable is still with us if we launch a ConsoleHost from the ISE (there’s a button for that). The environmental variable option works beautifully for my upcoming profile script project. I’ll link that from here when it’s up, and you’ll already understand that piece of it!
So it’s been included, the environmental variables are presented as a drive by PowerShell. The following command will show all of these variables. If you see some in there that you can use, then do so. It’s always better to use $env:COMPUTERNAME, than it is to hard code a computer name inside your functions.
Get-ChildItem -Path env: Name Value ---- ----- ALLUSERSPROFILE C:\ProgramData APPDATA C:\Users\tommymaynard\AppData\Roaming CommonProgramFiles C:\Program Files\Common Files CommonProgramFiles(x86) C:\Program Files (x86)\Common Files CommonProgramW6432 C:\Program Files\Common Files ... USERNAME tommymaynard USERPROFILE C:\Users\tommymaynard Variable This is my standard, environmental variable. windir C:\Windows
Okay, now we’re really done with today’s post, and oh, hey look, there’s our $env:Variable variable again.