terminal
terminal copied to clipboard
microsoft
Inherited environment variables don't work (for the very first tab)
Windows Terminal version
1.18.2822.0
Windows build number
No response
Other Software
No response
Steps to reproduce
- Launch wt with powershell
- execute
$env:path+=";FOO_BAR" - execute
wt - execute
$env:pathin new terminal instance
Config already contains: "compatibility.reloadEnvironmentVariables": false
Expected Behavior
Environment variables MUST be inherited as is the case for ages and every other terminal on Windows. This changes causes massive issues for us as it's no longer possible to transport environment variables down the chain.
Actual Behavior
Environment variables are not inherited.
Hi,
I was about to open the same issue, and I have a bit more to add.
There is a new (to me at least) advanced setting that defaults to start in a new environment, ignoring the one we were called from. I tried to change it.
Now, that works, but not for the very first tab after running wt. That one always starts in an empty environment. Subsequent ones do indeed honour the setting.
At least this is my current understanding.
I coulda swore we fixed this in #15897, which was cherry-picked to 1.18 in f2426c9ba72f5bafaef249cdaf622bcfa567b06a which does look like it's in v1.18.2822.0: https://github.com/microsoft/terminal/compare/v1.18.1462.0...v1.18.2822.0 ...
Config already contains: "compatibility.reloadEnvironmentVariables": false
where in the settings do you have that/? In the original 1.18 builds that was a global setting, but we moved that to be per-profile in 1.18 stable. There's code that should auto-migrate that to be per-profile, but maybe that didn't work?
@zadjii-msft I changed the default value using the UI, using the version i posted, after doing some research on why the issue might occur in the first place.
It's also very, very worrying that the it defaults to true which is a massive breaking change and a very strange difference to every other application running on Windows.
It defaults to true because inheriting the env vars was immensely unreliable. We had no end of bug reports of env vars being inherited bizarrely based off whether the app was launched from the Start menu, the run dialog, File Explorer itself, on and on[^1]. It created spooky action at a distance.
Furthermore, it didn't really make sense in a world where all terminal windows are one process. In 1.18 all the windows are owned by a single process, so "inheriting" from the terminal itself is a little wacky - they would theoretically only inherit from the first terminal you spawned. Even if you tear a tab off, spawn a third window, close the first - it's all the same process as the first launch. Refreshing the variables is just easier.
Instead, we tried to make the Terminal launching a process act more like you ran the thing from the Run dialog (or Start or whatever). Opening a new Terminal tab/pane just starts fresh.
Now, that works, but not for the very first tab after running
wt. That one always starts in an empty environment. Subsequent ones do indeed honour the setting
Huh, fascinating. That's a good observation. I wonder if that helps explain why this doesn't seem to repro with wt --inheritEnvironment alone.
[^1]: we believe there was some appx infrastructure here that was trying to be helpful but ultimately getting in the way. Hard to know for sure.
Ah, i wasn't aware of --inheritEnvironment.
Using that works, in my case.
I tried to find out which args wt accepts, but calling wt --help only contains a very small subset of supported args.
If it would have been included there or at least a hint at where one could find more information about supported args, that would have helped a lot.
It defaults to
truebecause inheriting the env vars was immensely unreliable. We had no end of bug reports of env vars being inherited bizarrely based off whether the app was launched from the Start menu, the run dialog, File Explorer itself, on and on1. It created spooky action at a distance.
I dont fully understand this: if env var were not inheritable, I suspect countless applications would stop working.
bash, cmd to name some common competitors inherit.
Furthermore, it didn't really make sense in a world where all terminal windows are one process. In 1.18 all the windows are owned by a single process, so "inheriting" from the terminal itself is a little wacky - they would theoretically only inherit from the first terminal you spawned. Even if you tear a tab off, spawn a third window, close the first - it's all the same process as the first launch. Refreshing the variables is just easier.
Before I found the setting I thought this was the case and it would have been game over. I was about to ask if there is an option to have a 2nd terminal process rather than attaching to an existing one.
But in all cases, I think a clear explanation of what does what will be necessary (since a lot of users will expect a bash-like behaviour).
Remember - the Terminal is not a shell. Shells still inherit from each other (e.g., $env:path+=";FOO_BAR" ; cmd.exe /k echo %path% will work as expected). But when the Terminal launches a profile, it's cleaner to give the shell a fresh env block to start with. As if the shell had been launched directly. You don't want the spooky action of inheriting from the terminal emulator itself.
I believe we also made wt -- foo.exe (with an explicit commandline, not just defaulting to the default profile) default to --inheritEnvironment, because in that case, the user is more or less saying "launch this process (in the terminal)", which is much more like "I want to spawn a subprocess".
There are more notes in https://github.com/microsoft/terminal/issues/15496#issuecomment-1692450231
Understood, I was not precise.
I tried https://github.com/microsoft/terminal/releases/tag/v1.19.2831.0 and things seem to work better.
Now, the first shell honours --inheritEnvironment which is good enough for me.
This is true regardless if there is already a terminal running or not.
Other tabs don't follow, but maybe this is where the additional settings matter. With tabs moving around it is not easy to say "inherit what", but I don't need it.
For my particular case, 1.19 seems to fix it.
When creating a new window with wt -w new-name, I'd expect all tabs opened in the window, including those opened later to inherit the environment of the caller. This was the old default behavior.
But now even with --inheritEnvironment, the environment is only passed to the current tab. Please bring back a way to have per-window environment variable rather than just per-tab.
Update: It appears --inheritEnvironment works only for the tab being launched, while disabling reloadEnvironmentVariables^1 works only for the "new tab" button. So using both together achieves the expected behavior
