vscode: Extension Host Failure - Error interaction with MATLAB code on macOS Catalina

cc: @bpasero – Verified

I talked with @deepak1556 in our Monday call and we think that removing this variable here should be fine:

https://github.com/microsoft/vscode/blob/e557e8bcc3ca6b4569eee3f6b746f00b4572db56/src/vs/workbench/services/extensions/electron-browser/localProcessExtensionHost.ts#L160

This means that the variable will never reach extensions, but my understanding is that people only want it for task execution which currently does not happen in the extension host (iirc).

To clarify: if we switch to open command, none of the shell process environment or anything we configure in our CLI scripts ends up in the process environment of the VSCode window? That would be pretty bad and we then need an alternative for how to getting these variables in. Even when running out of sources, code.sh defines many variables:

yeah thats correct, the only way I see now is to pass them via command line flags and modify process.env in the app, should figure a good solution for this.

Even when running out of sources, code.sh defines many variables:

we are not gonna change the out of sources cli wrapper, so this one should not be an issue.

Sounds good, but I am not familiar with the task execution system to verify if this will work fine. Atleast would be good to verify with the sample from #88306 . Also if there are other use cases, I would like to capture it in this issue.

👍

That won’t be true with #104470

To clarify: if we switch to open command, none of the shell process environment or anything we configure in our CLI scripts ends up in the process environment of the VSCode window? That would be pretty bad and we then need an alternative for how to getting these variables in. Even when running out of sources, code.sh defines many variables:

https://github.com/microsoft/vscode/blob/46860a105b2f2e115970ad0d54f5a39d5add9cc5/scripts/code.sh#L39

My understanding is that DYLD_LIBRARY_PATH might have negative impact on VSCode itself, so a solution that allows to use DYLD_LIBRARY_PATH in tasks (or anywhere else in extensions code) should support this variable exclusively for that child process, right?

Yup thats correct

Maybe one approach would be to filter DYLD_LIBRARY_PATH by renaming it to VSCODE_DYLD_LIBRARY_PATH and then ensuring to put it back in selected places where users really want it?

Sounds good, but I am not familiar with the task execution system to verify if this will work fine. Atleast would be good to verify with the sample from https://github.com/microsoft/vscode/issues/88306 . Also if there are other use cases, I would like to capture it in this issue.

Not sure I follow what you said, we have to ensure VSCODE_CLI is present for any invocation of VSCode from the command line.

That won’t be true with https://github.com/microsoft/vscode/pull/104470 , since the app won’t be invoked from the shell. We are trying to emulate the behavior of opening from finder. I just remembered that we missed VSCODE_CLI context in that PR, so wanted to capture it. I haven’t thought about the way forward, we can continue the discussion in the associated issue.

Doesn’t cli.ts launch the app as a child process, so the env variables it launches gets propagated all the way down because of process.env. For example.

$ export ABC=1 $ code-insiders vscode/ $ check process.env.ABC in renderer process $ check process.env.ABC in extension host process.

thats why the author didn’t see the crash when launching without the cli wrapper