Locally exported environment variables are overwritten by ~/.bash_profile when using code .

[lukehoban]

Per microsoft/vscode-go#141, there appears to still be an issue with how env vars are passed into Code, even after the fix for #560.

Steps to reproduce:

1. have export FOO=1 in your .bash_profile
2. ensure your function to start visual studio code looks like this code () { VSCODE_CWD="$PWD" open -n -b "com.microsoft.VSCode" --args $* ;}
3. open a terminal session
4. export FOO=2 in your terminal session
5. open code .
6. open developer tools, and eval process.env["FOO"]

Expected: Foo should be 2
Result: FOO will be 1

But the thing that's really odd is that if you skip step (1) (remove this from you .bash_profile), you will see Foo set to 2. So in that case, the local environment is getting passed in.

It seems like this must be either a problem with how vscode is setting up the env vars, or how open in OS X behaves.

[joaomoreno]

After discovering that a doubly-clicked app on OSX would not inherit the users's shell environment we implemented the following: at startup, Code spawns the user's default shell, extracts its environment and sets that as its own. Let's call this process: ⚡.

So, here's what's happening:

• This only repros if Code is not running yet. If it is, new windows will be opened with the expected environment.
• FOO is 1 because ⚡ is triggered at startup thus overwriting FOO.
• When skipping step 1, ⚡ will still run but no FOO will be in there. No overwriting happens.

A possible fix would be to detect whether we are spawned via double-click or the code shortcut and conditionally run ⚡. The VSCODE_CWD variable could be a good indicator. @bpasero what do you think?

[bpasero]

@joaomoreno so are you proposing that we do the detection only when someone double clicks from the desktop but when running from the command line we don't do this because we assume the environment is correctly passed in? I think we only set VSCODE_CWD from the script so it is a fair guess to say that someone launched from the command line when this one is present.

[voelzmo]

Sounds like a reasonable proposal to me. I'm wondering if that's what e.g. atom is doing? Because for atom the same setup works pretty well for me.

[mucaho]

+1, I'm currently trying to package vscode for the NIXOS package manager and having the same problem.
If I append to LD_LIBRARY_PATH before calling ./scripts/code.sh, it gets overwritten with the default LD_LIBRARY_PATH (presumably from .bash_profile), which leads to electron crashing because it can't find the shared libraries.

EDIT1:
The culprit is located in src/vs/workbench/electron-main/main.ts, which calls src/vs/base/node/env.ts#getUserEnvironment.

Changing

Object.assign(process.env, userEnv);

to

for (var userEnvKey in userEnv) {
    if (!(userEnvKey in process.env))
        process.env[userEnvKey] = userEnv[userEnvKey];
}

should prevent overwriting of existing environment variables.

EDIT2:
However, after patching the code in EDIT1, the extension host still complained about missing shared libraries.
I've managed to solve the issue by patching the rpath/runpath of electron's ELF executable.

[joaomoreno]

@bpasero This is actually now trivial to implement, given the new cli launcher. We can simply prevent doing this when launching from it. 🎆

[joaomoreno]

To verify on OS X:

• Launch Code from the command line (e.g. code).
• Open dev tools and type process.env. Take note of one of the env variables that was set up in your .bashrc, for example NVM_BIN, in case you have it.
• Close Code.
• Launch Code again, overwriting that variable: NVM_BIN=awesome code
• Inspect process.env again, the variable should be overwritten.

[saml]

As per https://github.com/Microsoft/vscode/blob/71f93aa38eed15c56d23845904e4dab245b86cc3/src/vs/workbench/electron-browser/main.ts#L53-L55 , need to set VSCODE_CLI=1 envvar to make this work.

For example, using latest release:

Version 1.1.1
Commit def9e32467ad6e4f48787d38caf190acbfee5880
Date 2016-05-13T13:38:00.094Z
Shell 0.37.6
Renderer 49.0.2623.75
Node 5.10.0

The following still gets overwritten:

GOPATH=/tmp code . 
# shell's rc exports GOPATH=/something/different
# process.env.GOPATH=/something/different, not /tmp

The following works as expected:

GOPATH=/tmp VSCODE_CLI=1 code .
# even though shell's rc exports GOPATH=/something/different,
# process.env.GOPATH=/tmp

[joaomoreno]

We now set this variable in all places that code should launch from the command line.

So, what is the full location of your global code command?

[saml]

Using linux.

> which vscode
/home/saml/bin/vscode
> file /home/saml/bin/vscode
/home/saml/bin/vscode: symbolic link to `/home/saml/opt/VSCode-linux-x64/code' 

Just noticed there's /home/saml/opt/VSCode-linux-x64/bin/code bash script as well. Using that does not set VSCODE_CLI=1 either.

It feels like executing login shell behavior could be inverted: by default login shell isn't executed. But Mac OSX app launcher(?) would execute login shell if needed envvars aren't set.

[Tyriar]

Try pointing the symlink at /home/saml/opt/VSCode-linux-x64/bin/code

[joaomoreno]

It's just that it's hard to identify when that situation occurs (double click on OS X, or Linux even).

Yes, you should point to /home/saml/opt/VSCode-linux-x64/bin/code. Note that you no longer need a custom alias; when installing code via the deb or rpm package, you'll get a global alias pointing to the right place.

VSCODE_CLI isn't set in the shell script, but in the JavaScript that follows it.

[saml]

That works. When I tested bin/code before, I had other vscode instances running