-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SessionName environment variable undefined #14711
Comments
What is this variable? $ dir env:WT*
Name Value
---- -----
WT_PROFILE_ID {574e775e-4f2a-5b96-ac1e-a2962a402336}
WT_SESSION c3f793c5-98bd-40f8-a8cd-73fe0027b5c7 |
It's an environment variable provided by the Windows session manager that indicates how a user is connected to the machine (via remote desktop, sitting at the keyboard, etc.). We'll look into this. Terminal is changing how it handles environment variables in #12516, after which it will regenerate them exactly the same way the Windows profile management service does. Perhaps that will fix this -- or at least make it clear why it doesn't work. |
I hear it for the first time. Never seen this variable. Should it be in the WT Preview? |
I've looked into it a bit more. Apparently the variable is inherited from explorer.exe and is undefined in environments that are launched as services or scheduled task, or started manually via task manager. So it being unavailable in WT may be unexpected, but also I never should've relied on it. |
Thanks for following up. In light of that, we're going to close this one out. |
Windows Terminal version
1.15.3465.0
Windows build number
10.0.1945.2486
Other Software
No response
Steps to reproduce
Start Terminal. Make sure to start Terminal directly - not cmd.exe or powershell.exe which get redirected to Terminal (different behaviour).
Output the environment variable named SessionName.
cmd.exe:
if not defined SessionName (echo undefined) else echo %SessionName%
Expected Behavior
Environment variable "SessionName" should be undeifined when terminal is started elevated/as admin.
IIRC, it might actually be defined if the invoking user is member of the Network Operators group.
When started normally as invoker/unelevated, SessionName should contain either an "RDP-Tcp#Session" string (only when using RDP) or "console" (physically using the PC).
In other words, conhost's behaviour is expected.
Actual Behavior
Environment variable "SessionName" is undefined, regardles of whether the terminal is started normally or elevated/as admin.
If anyone else is having the same problem, my current workaround is to modify
settings.json
:add
"commandline": "cmd.exe /D /C \">NUL 2>&1 fltmc.exe || set \"SessionName=buggy\" & cmd.exe\"",
next to
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
The text was updated successfully, but these errors were encountered: