Code on insiders started from GUI does not pick up environment variables on Linux

[nwgh]

• VSCode Version: 1.1.0-insider (1f06577)
• OS Version: Fedora 23

Steps to Reproduce:

1. Launch vscode-insiders using the app launcher
2. Attempt to build mozilla/gecko-dev with a vscode configuration from nwgh/gecko-vscode and zsh configuration from nwgh/homedir (this uses the "Full Build" task, though I suspect any task would exhibit the same behavior).
3. While the build succeeds, the output is in an unexpected directory.

Let me expand in a way that doesn't involve steps - I use the MOZCONFIG environment variable to tell the firefox build system how to build (what compiler to use, what object directory to use, config options, etc) - this environment variable points to a file that contains the instructions for the build system. When I build from the cli, or from an instance of code started from the cli, this works fine (my environment is picked up just fine). However, when I run from an instance of code started from the GNOME app launcher, my environment is not picked up at all, causing confusion.

I have put minimal files that exhibit this behavior at https://gist.github.com/nwgh/c7b71148908bea753a78685ffad03210

From that gist, .zshrc should go in $HOME, mach should go in some directory (call it srcdir), and tasks.json should go in srcdir/.vscode. Then, open code, open srcdir in code, and run the Full Build task.

This worked on 0.10.15-insider (my previous build on the same machine - sorry I don't have a better build to work from for bisecting).

This behavior does not happen on my mac install of the exact same version of code.

For now, I have worked around this by making my build task a shell script that invokes zsh as an interactive shell (to pick up my environment) with a script that calls the firefox build system. I could also likely work around this with os-specific properties in my tasks.json that replicates the work my shell does, or some extra layer of indirection within my mozconfig that replicates the work my shell already does (since a mozconfig is just a shell script). However, that seems... ugly, and prone to break in the future when I inevitably change something in my shell config.

[bpasero]

Might also be @dbaeumer for tasks.

[dbaeumer]

Checked and the task runner merges a process.env with the provided env. Since this only seem to happend when started from the GUI I doubt that this is caused by the task runner.

[nguymin4]

• VSCode Version: 1.1.0
• OS Version: Ubuntu 16.04

I just update vscode to 1.1.0 today and have similar problem with using vscode-eslint. Starting vscode from terminal works fine but starting from GUI (clicking on vscode icon) doesn't because vscode does not pick up PATH. Everything work ok if I use vscode 1.0.0.

[joaomoreno]

What do you get when running the following command?

$SHELL -ilc env

Are you sure Code is not running when launching it from the GUI?

[nwgh]

Code was definitely not running prior to starting from the GUI (this happened immediately after a cold boot).

The output of $SHELL -ilc env is at https://gist.github.com/nwgh/78e8db860bc09e4d9278b463eadce79e (I wasn't sure whether you wanted output if it's run from a terminal or as a task within code, so I added both, as well as the tasks.json used to run the command).

Looking at the output, there is no discernable difference. I haven't yet updated to the latest build on this machine, so I'll double-check to make sure the problem still exists with my real tasks.json

[joaomoreno]

It seems that the MOZCONFIG variable is there in all situations, even when run from that task... I thought you mentioned in the first post that that variable is not set when running within a task? Do you mind adding an env to the options of this sample task, similarly to your real life scenario? Maybe we'll find that there the MOZCONFIG variable would not be set...

[nwgh]

Yes, that is the most disturbing part of this :) When my command and args are set up as in the comment from yesterday, the environment variables are set up just fine (including MOZCONFIG). Same thing if I add an env property to the options in the sample task.

If I do nothing but change the command to env (and drop the args property, so as to not confuse env) then the environment variables aren't set up properly (and this behaves the same when trying to run the actual build - MOZCONFIG is never picked up, so my build config is not what I expect).

[nwgh]

Oh, and just for completeness, the behavior persists even with latest insiders build 1.1.1 commit def9e32

[joaomoreno]

@dbaeumer Given these findings, I believe this is somewhere in the tasks framework.

[dbaeumer]

I retested and debugged the task code and it merges the environment and doesn't replace it.

@nwgh just to clarify:

{ 
     // See http://go.microsoft.com/fwlink/?LinkId=733558 
     // for the documentation about the tasks.json format 
     "version": "0.3.2", 
     "command": "${env.SHELL}", 
     "isShellCommand": true, 
     "args": ["-ilc", "env"], 
     "options": {"cwd": "${workspaceRoot}"}, 
     "showOutput": "always", 
     "tasks": [ 
         { 
             "taskName": "Full Build", 
             "suppressTaskName": true, 
             "isBuildCommand": true, 
         } 
     ] 
 } 

this worlks, but

{ 
     // See http://go.microsoft.com/fwlink/?LinkId=733558 
     // for the documentation about the tasks.json format 
     "version": "0.3.2", 
     "command": "env", 
     "isShellCommand": true, 
     "options": {"cwd": "${workspaceRoot}"}, 
     "showOutput": "always", 
     "tasks": [ 
         { 
             "taskName": "Full Build", 
             "suppressTaskName": true, 
             "isBuildCommand": true, 
         } 
     ] 
 } 

doesn't. Right.

[dbaeumer]

And just to double check: the second one even works if you start vscode from a terminal where MOZCONFIG is already part of the environment. How do you set MOZCONFIG into the env in the first place?

[nwgh]

@dbaeumer that's all correct - first works when starting from GUI, second doesn't. Both work when starting from CLI.

MOZCONFIG is set in a (os-specific) rc script that is sourced from my ~/.zshrc

I'm now wondering if this isn't getting picked up because whatever source code uses to get environment variables on linux isn't running zsh as an interactive shell (which means ~/.zshrc would never get sourced). I'll try putting stuff in ~/.zprofile (which is used for login shells) and ~/.zshenv (used by all shells) and report back - maybe I just need to refactor my init scripts a little bit!

[nwgh]

Yeah, that explains it (on linux, at least - the fact that it all works fine on os x is still a little baffling, and probably bears investigating). If I set an environment variable in ~/.zprofile or ~/.zshenv, those get picked up by code run from the GUI. I shall now attempt to refactor my shell rc scripts in an attempt to not break anything, and also to make this all work on both linux and mac :)

[joaomoreno]

We run whatever shell is in SHELL... so what do you get with echo $SHELL?

[nwgh]

with "command": "echo" and "args": ["${env.SHELL}"] the output is /usr/bin/zsh (same as if I run echo $SHELL from the CLI)

[dbaeumer]

@nwgh can I ask you for another favor: for the case where it doesn't work could you do the following:

• open Dev tools (Help>Toogle Developer Tools)
• in a console, check if process.env['MOZCONFIG'] is set.

[joaomoreno]

Found the issue.

Due to #1033, Code will not read the $SHELL's environment if it detects that it was run from the command line, via our new cli launcher; it sets a variable which is later listened upon.

Unfortunately, that solution has a problem: the Debian and RPM packages (cc @Tyriar) set up an application shortcut which points to that cli launcher. So, when launching Code from those application shortcuts, it won't have the correct environment.

We need to look into a different fix for #1033: possibly we can figure out whether we are in a TTY...?

[nwgh]

@dbaeumer it does not exist (which I imagine you could figure out based on @joaomoreno 's latest comment)

@joaomoreno woohoo! sounds like there's at least the hint of a path towards a fix for this.

Thanks, everyone! The interactions on this bug have made me ❤️ code even more 😄

[Tyriar]

I'm not sure I understand the problem, @joaomoreno how is launching from desktop entry any different from the CLI? Would the solution be to point to the binary instead as that's probably no issue (it may be preferable even).

[joaomoreno]

When launching from the CLI, the correct env is already there. That could be one solution, but I also don't mind doing the proposed one there, since it might be better anyways just in itself.

[Tyriar]

@nwgh does the problem go away when you change the Exec line in /usr/share/applications/code.desktop to:

Exec=/usr/share/code/code %U

Not sure if Gnome picks up on these changes immediately or if you need to nudge it somehow.

[nwgh]

@Tyriar yes, that appears to fix the issue, as well.

[Tyriar]

I think changing that may also fix #6593

[Tyriar]

@nwgh I pushed 069e325 to my branch that will be merged in for the June release, you'll be able to test it on the Insiders build in a week or so.

[joaomoreno]

Awesome, then I'll not do anything here. 👍