Support using a "clean" environment for the terminal

[praenubilus]

• VSCode Version: 1.30, 1.31, 1.33
• OS Version: Ubuntu 18.04/ MacOS 10.14 Mojave

Steps to Reproduce:

1. From OS terminal, type echo $PATH, you may see values similar to following:

/Users/xxx/anaconda3/bin:/Users/xxx/anaconda3/condabin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

2. Open a vscode instance, in the integrated terminal type echo $PATH, now the value may look like following:

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/xxx/anaconda3/bin:/Users/xxx/anaconda3/condabin

The CONTENT in two $PATH values are the same, BUT in different order. Problems it may cause: some system configuration depends on the first executable value they can find in the $PATH. Different $PATH value order will have different default program being used. In previous example, the value in step 1 will use python3 and pip3 from anaconda. But in vscode integrated terminal, the $PATH value in step 2 will use the python2 and pip2 in /usr/local/bin. Even you activate a virtualenv in integrated terminal, it will still use the wrong virtual env. More details and a proposed workaround can be seen in vscode-python #4434.

This has been observed on both MacOS and Ubuntu. I don't have windows computer, but I guess that may also have the same issue. Some related issues can be found in this issue vscode-python #4668.

Now I'm trying to fix this issue with a pull request. But I need some help to indicate me to the correct location in the code base. I also addressed this question on StackOverflow:

Through my own observation, I found the root cause may be: after some steps, somewhere during the create terminal process, the actual environment variable values(specific to PATH) has been reordered/changed. Maybe it is being processed for remove duplication.

I download the vscode codebase(1.33) and follow the debugging until method createProcess in source file src/vs/workbench/contrib/terminal/electron-browser/terminalProcessManager.ts. What I have found is: even after the terminal instance has been created, the env.PATH in the main process has NOT been changed. For ptyProcess, the constructor takes options(which contains env) as input, but I cannot find any env related property in created ptyProcess. And after the terminal instance created, the debugging ends, integrated terminal appears in the workbench. I get lost after terminal instance created, can someone from the core team or used to working on integrated terminal module indicate me to the right place in the codebase so I can try to solve the issue? There is not enough documents on internet or comments in the source code can help me find/locate the environments changing during/after the terminal instance creation.

[praenubilus]

Also, if I want to debug vscode platform source code, where should I expect a User Settings or Workspace Settings so I can add some customized stuff in it?

[DonJayamanne]

Current workaround is:

"terminal.integrated.env.osx": {
		"PATH": ""
}

[Tyriar]

The reason this happens is because on mac and Linux there are two ways to launch VS Code:

• From a terminal (ie. the environment has already been setup by running .bashrc/.bash_profile
• From the "dash" in which case VS Code runs $SHELL -ilc to source the "development environment"

This sets up the main process environment which is inherited by each VS Code window, its tasks, debug sessions and terminals. Below explain this in detail:

Ubuntu launching from terminal

• Ubuntu (log in sources ~/.bash_profile)
  • Terminal (sources ~/.bashrc)
    • VS Code main process
      • VS Code renderer process*
        • VS Code terminal (sources ~/.bashrc)
        • VS Code task*
        • VS Code debug session*

Ubuntu launching from dash

• Ubuntu (log in sources ~/.bash_profile)
  • VS Code main process (sources ~/.bash_profile because VSCODE_CLI is not set)
    • VS Code renderer process*
      • VS Code terminal (sources ~/.bashrc)
      • VS Code task*
      • VS Code debug session*

macOS launching from terminal

• macOS
  • Terminal (sources ~/.bash_profile)
    • VS Code main process
      • VS Code renderer process**
        • VS Code terminal (sources ~/.bash_profile)
        • VS Code task**
        • VS Code debug session**

macOS launching from dock

• macOS
  • VS Code main process (sources ~/.bash_profile because VSCODE_CLI is not set)
    • VS Code renderer process**
      • VS Code terminal (sources ~/.bash_profile)
      • VS Code task**
      • VS Code debug session**

* needs ~/.bashrc already sourced
** needs ~/.bash_profile already sourced

The underlying problem is:

When a terminal is launched, it needs to run its launch script again; .bashrc on Linux and .bash_profile on macOS (because terminal.integrated.osx.shellArgs defaults to [ "-l" ]). This will shuffle the environment based on what the user's scripts does, and can mess things up if their script is not idempotent.

So as for fixing this issue once and for all this will be a little tricky, unfortunately it's not just as easy as holding onto the original environment and using that for the terminal instead of the one generated by getShellEnvironment, that will only work when launching VS Code from the dock/dash but not when run through the terminal.

I propose we fetch the environment of the parent process of the code executable which will probably be systemd on Linux or the root process on macOS, we can do this on Linux by running and parsing cat /proc/<pid>/environ on Linux, and ps eww <pid> on macOS.

It's worth noting that this could break some people's set up and potentially cause some other unexpected issues as before it was an assumption that the terminal process uses the environment of VS Code's window. Maybe this should even be an option in settings, something like "terminal.integrated.useWindowEnvironment": false?

[Tyriar]

@praenubilus if you wanted to put together a PR for this I would stick the fetching of the environment code insider electron-browser/terminalService and grab that inside TerminalProcessManager instead of basing it on process.env here:

https://github.com/Microsoft/vscode/blob/d3443fd68d625c980325e1571066850e943dfbef/src/vs/workbench/contrib/terminal/browser/terminalProcessManager.ts#L128

I think for Windows we always want the old behavior.

[praenubilus]

@Tyriar Thanks for the information. Can you answer my another question: if I want to debug with customized settings, (for example "terminal.integrated.env.osx": { "PATH": ""} ) where should I expect a User Settings or Workspace Settings file I can play with?

[Tyriar]

@praenubilus I haven't touched any debugging stuff with extensions, this might be relevant?

https://github.com/Microsoft/vscode/blob/1615a36eb45182de5e34c53cfdd5b3bce8cddbf3/src/vs/vscode.d.ts#L8484-L8500

[auchenberg]

Ping @DonJayamanne

[DonJayamanne]

Yes, this might help, however the downside of ALWAYS using this approach is the fact that we'll end up printing a tonne of environment variables (EVERYTHING) to the console in the terminal window.
Will check if we can try to perform a diff, though that too might not work due to the current process (VSC - Env Variables) vs default shell Process (Env variables)

Will double check this and get back.