starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-24 07:54:35 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

wt ignore env-vars set in the script launching it, due to new "auto reload system env vars with new window / tab" #19959

New Issue
Closed
opened 2026-01-31 06:58:38 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 06:58:38 +00:00
Owner
Copy Link

Originally created by @eZioPan on GitHub (May 25, 2023).

Update:

for anyone encounter the same problem:

I suggest to set envrionment variables in Windows Terminal, and do not set env vars in script and let wt inherit it.

If you use powershell script, here is my solution:

$pre_cmd_string = {
    # do common pre run setup, set env vars, run some commands, etc...
    # DO NOT WRITE ANY COMMENTS IN THIS BLOCK, AND REMEMBER REMOVE US TOO
}.ToString()

<# prepare first pane...#>

$first_cmd_string = $pre_cmd_string + "`n" + { <#per pane setup code#> }.ToString()
$first_cmd_bytes = [System.Text.Encoding]::Unicode.GetBytes( $first_cmd_string )
$first_cmd_enc = [Convert]::ToBase64String( $first_cmd_bytes )

<# ... and #>
<# prepare rest of panes as above...#>

<# launching wt and launching powershell with EncodedCommand parm #>

wt pwsh.exe -ExecutionPolicy ByPass -NoExit -EncodedCommand $first_cmd_enc

Windows Terminal version

1.18.1421.0

Windows build number

10.0.19045.0

Other Software

PowerShell 7.4

Steps to reproduce

  1. open powershell open a standalone powershell commandline window (not in wt window)
  2. custom a env var $Env:MY_VAR="MY_VAL"
  3. launch a new Windows Terminal wt
  4. in new window (running powershell), type echo $Env:MY_VAR
  5. Nothing show up

after I disable compatibility.reloadEnvironmentVariables in global settings.json, new wt window inherit env var set in powershell

Expected Behavior

No response

Actual Behavior

see above

Originally created by @eZioPan on GitHub (May 25, 2023). ### Update: for anyone encounter the same problem: I suggest to set envrionment variables in Windows Terminal, and do not set env vars in script and let wt inherit it. If you use powershell script, here is my solution: ```powershell $pre_cmd_string = { # do common pre run setup, set env vars, run some commands, etc... # DO NOT WRITE ANY COMMENTS IN THIS BLOCK, AND REMEMBER REMOVE US TOO }.ToString() <# prepare first pane...#> $first_cmd_string = $pre_cmd_string + "`n" + { <#per pane setup code#> }.ToString() $first_cmd_bytes = [System.Text.Encoding]::Unicode.GetBytes( $first_cmd_string ) $first_cmd_enc = [Convert]::ToBase64String( $first_cmd_bytes ) <# ... and #> <# prepare rest of panes as above...#> <# launching wt and launching powershell with EncodedCommand parm #> wt pwsh.exe -ExecutionPolicy ByPass -NoExit -EncodedCommand $first_cmd_enc ``` ### Windows Terminal version 1.18.1421.0 ### Windows build number 10.0.19045.0 ### Other Software PowerShell 7.4 ### Steps to reproduce 1. ~open `powershell`~ open a standalone `powershell` commandline window (not in `wt` window) 2. custom a env var `$Env:MY_VAR="MY_VAL"` 3. launch a new Windows Terminal `wt` 4. in new window (running powershell), type `echo $Env:MY_VAR` 5. Nothing show up after I disable `compatibility.reloadEnvironmentVariables` in global `settings.json`, new wt window inherit env var set in powershell ### Expected Behavior _No response_ ### Actual Behavior see above
claunia added the Needs-TriageIssue-Bug labels 2026-01-31 06:58:38 +00:00
claunia commented 2026-01-31 06:58:39 +00:00
Author
Owner
Copy Link

@eZioPan commented on GitHub (May 25, 2023):

I might not think it's really a issue, but this change might break some script. Should the new "auto-reload system environment variable" feature set to be "opt-in", rather than "default-on"?

related change #14999

@eZioPan commented on GitHub (May 25, 2023): I might not think it's really a issue, but this change might break some script. Should the new "auto-reload system environment variable" feature set to be "opt-in", rather than "default-on"? related change #14999
claunia commented 2026-01-31 06:58:39 +00:00
Author
Owner
Copy Link

@ianjoneill commented on GitHub (May 25, 2023):

after I disable compatibility.reloadEnvironmentVariables in global settings.json, new wt window inherit env var set in powershell

I can't reproduce this behaviour:

https://github.com/microsoft/terminal/assets/5821575/386bf739-a35f-4385-9443-0013fb6b35fa

I don't think #14999 is at fault here - I think it's likely #5000. As of #5000 there is one overarching WindowsTerminal.exe process that manages all of the windows, whereas in terminal 1.17 and before each window had it's own WindowsTerminal.exe process.

As of version 1.18, when compatibility.reloadEnvironmentVariables is set to false, it's going to be that single long-running WindowsTerminal.exe that has it's environment block copied and given to the new shell process. It's environment won't contain the MY_VAR variable.

image

In version 1.17, the new WindowsTerminal.exe that's spawned by running wt is going to be the one that has it's environment block copied and given to the new shell process - it's environment will contain the MY_VAR variable.

image

(Apologies for the screenshots being from different PCs running different Windows versions - it was easier for logistical reasons.)

@ianjoneill commented on GitHub (May 25, 2023): >after I disable compatibility.reloadEnvironmentVariables in global settings.json, new wt window inherit env var set in powershell I can't reproduce this behaviour: https://github.com/microsoft/terminal/assets/5821575/386bf739-a35f-4385-9443-0013fb6b35fa I don't think #14999 is at fault here - I think it's likely #5000. As of #5000 there is one overarching `WindowsTerminal.exe` process that manages all of the windows, whereas in terminal 1.17 and before each window had it's own `WindowsTerminal.exe` process. As of version 1.18, when `compatibility.reloadEnvironmentVariables` is set to `false`, it's going to be that single long-running `WindowsTerminal.exe` that has it's environment block copied and given to the new shell process. It's environment _won't_ contain the `MY_VAR` variable. ![image](https://github.com/microsoft/terminal/assets/5821575/736acca3-1003-4b4a-a63a-c4f6808bfb29) In version 1.17, the new `WindowsTerminal.exe` that's spawned by running `wt` is going to be the one that has it's environment block copied and given to the new shell process - it's environment _will_ contain the `MY_VAR` variable. ![image](https://github.com/microsoft/terminal/assets/5821575/a24f923f-6f7c-486e-82ec-12721b21dbfc) (Apologies for the screenshots being from different PCs running different Windows versions - it was easier for logistical reasons.)
claunia commented 2026-01-31 06:58:40 +00:00
Author
Owner
Copy Link

@eZioPan commented on GitHub (May 26, 2023):

thanks for reply!

I can confirm that no matter how compatibility.reloadEnvironmentVariables sets, launching a new wt in a wt does not inherit env var.

maybe I wasn't clear, on the 1st step of my first post, I do means open a powershell commandline itself, other than open wt and there is a powershell running on it.

mybe we find 2 different situations that have similar behavior?

@eZioPan commented on GitHub (May 26, 2023): thanks for reply! I can confirm that no matter how `compatibility.reloadEnvironmentVariables` sets, launching a new `wt` in a `wt` does not inherit env var. maybe I wasn't clear, on the 1st step of my first post, I do means open a `powershell` commandline itself, other than open `wt` and there is a powershell running on it. mybe we find 2 different situations that have similar behavior?
claunia commented 2026-01-31 06:58:40 +00:00
Author
Owner
Copy Link

@eZioPan commented on GitHub (May 26, 2023):

this could be a nasty task, that wt might need to ask parent process that launching it: which env var has been modified in parent process, which one is modified outside of parent process, then merge into the possible result.

@eZioPan commented on GitHub (May 26, 2023): this could be a nasty task, that `wt` might need to ask parent process that launching it: which env var has been modified in parent process, which one is modified outside of parent process, then merge into the possible result.
claunia commented 2026-01-31 06:58:40 +00:00
Author
Owner
Copy Link

@ianjoneill commented on GitHub (May 26, 2023):

Ah, opening a powershell window directly in the Windows console host, I can reproduce this behaviour.

If in the same powershell window you run a tiny program that calls the RegenerateUserEnvironment() function in shell32.dll (that the environment variable reloading code in Windows Terminal is based on), MY_VAR isn't printed either.

image

@ianjoneill commented on GitHub (May 26, 2023): Ah, opening a `powershell` window directly in the Windows console host, I can reproduce this behaviour. If in the same `powershell` window you run a tiny program that calls the `RegenerateUserEnvironment()` function in `shell32.dll` (that the environment variable reloading code in Windows Terminal is based on), `MY_VAR` isn't printed either. ![image](https://github.com/microsoft/terminal/assets/5821575/c9faf9ee-210e-4bc8-962b-3b5b1cc58713)
claunia commented 2026-01-31 06:58:41 +00:00
Author
Owner
Copy Link

@eZioPan commented on GitHub (May 26, 2023):

so, would you consider make compatibility.reloadEnvironmentVariables also a per profile settings / an env var / wt commandline argument, so that users can easily disable or enable it per profile / per session?

i used to write a powershell script, doing some env modification(mostly add msys2 into PATH), then launching wt, with 4 split panes, each runs a msys2 binary.

If I can disable auto-reload with a env var / wt commandline argument, then I can just add another line in my script before launching wt, that my old script would just run fine. and I also will be benefit from new auto-reload mechanism with a interactive use case.

@eZioPan commented on GitHub (May 26, 2023): so, would you consider make `compatibility.reloadEnvironmentVariables` also a per profile settings / an env var / wt commandline argument, so that users can easily disable or enable it per profile / per session? i used to write a powershell script, doing some env modification(mostly add msys2 into PATH), then launching wt, with 4 split panes, each runs a msys2 binary. If I can disable auto-reload with a env var / wt commandline argument, then I can just add another line in my script before launching wt, that my old script would just run fine. and I also will be benefit from new auto-reload mechanism with a interactive use case.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Bug Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#19959
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?