Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

VS Code always uses getUnixShellEnvironment if the first launch is from the GUI #55144

Closed
segevfiner opened this issue Jul 26, 2018 · 5 comments
Closed

VS Code always uses getUnixShellEnvironment if the first launch is from the GUI #55144

segevfiner opened this issue Jul 26, 2018 · 5 comments
Assignees
@bpasero
Labels
bug Issue identified by VS Code Team member as probable bug insiders-released Patch has been released in VS Code Insiders linux Issues with VS Code on Linux macos Issues with VS Code on MAC/OS X verified Verification succeeded workbench-cli VS Code Command line issues
Milestone
November 2020

Comments

@segevfiner
Copy link
Contributor

  • VSCode Version: 1.25.1
  • OS Version: Ubuntu 16.04.5 x86_64 (This is Linux and macOS only)

Steps to Reproduce:

  1. Open VS Code from the GUI (.desktop shortcut) (VSCODE_CLI will be unset)
  2. Open a separate terminal window and change your PATH, for example: Enter a virtualenv.
  3. Launch VS Code from that terminal: code ..
  4. Open the developer tools and check process.env. Your PATH will be reset to your shell's default.

The cause is that this code: https://github.com/Microsoft/vscode/blob/d983257e6f8db693962d0dba9a025678f50778fe/src/vs/code/node/shellEnv.ts#L83-L92

Is executed in the VS Code main process that gets it's environment variables from the first launch of VS Code instead of checking if the new environment that was received for this launch request is from the GUI or CLI.

Does this issue occur when all extensions are disabled?: Yes
@vscodebot
Copy link

vscodebot bot commented Jul 26, 2018

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

@weinand weinand assigned joaomoreno and unassigned weinand Jul 26, 2018
@segevfiner segevfiner mentioned this issue Jul 26, 2018
Closed
@segevfiner segevfiner mentioned this issue Aug 13, 2018
Closed
@joaomoreno
Copy link
Member

/duplicate #15452

@vscodebot vscodebot bot added the *duplicate Issue identified as a duplicate of another issue(s) label Aug 22, 2018
@vscodebot
Copy link

vscodebot bot commented Aug 22, 2018

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.

Happy Coding!

@vscodebot vscodebot bot closed this as completed Aug 22, 2018
@vscodebot vscodebot bot locked and limited conversation to collaborators Oct 6, 2018
segevfiner added a commit to segevfiner/vscode that referenced this issue Nov 19, 2018
@segevfiner
Correctly inherit/don't inherit the shell environment
910a40f 
`VSCODE_CLI` was checked from the main process, which had it set
depending on if the *first* launch of VS Code was launched from cli or
not, instead of whether the *current* launch has it set.

So I changed the check to checking the userEnv passed to the new browser
window.

Note that the assignment of `lazyEnv` and `userEnv` into `process.env`
was racing before! Which is a bug in and of itself. After this fix, the
`shellEnv`/`lazyEnv` overrides the passed in `userEnv`, but that can be
changed later if needed.

We are also always launching the shell now since `configuration.userEnv`
is not available yet when `lazyEnv` is initialized. It will require a
hack or some refactoring to fix, so I left that like this for now. Might
want to open an issue for future reference.

Fixes microsoft#55144
@bpasero bpasero assigned bpasero and unassigned joaomoreno Nov 21, 2020
@bpasero bpasero added bug Issue identified by VS Code Team member as probable bug workbench-cli VS Code Command line issues and removed *duplicate Issue identified as a duplicate of another issue(s) labels Nov 21, 2020
@bpasero bpasero added this to the November 2020 milestone Nov 21, 2020
@bpasero
Copy link
Member

bpasero commented Nov 21, 2020

This should be fixed now based on #108804 (comment)

@bpasero bpasero added the author-verification-requested Issues potentially verifiable by issue author label Nov 23, 2020
@github-actions github-actions bot removed the author-verification-requested Issues potentially verifiable by issue author label Nov 23, 2020
@bpasero
Copy link
Member

bpasero commented Nov 23, 2020

\closedWith 6f3fcd2

@bpasero bpasero added the author-verification-requested Issues potentially verifiable by issue author label Nov 23, 2020
@rzhao271 rzhao271 added linux Issues with VS Code on Linux macos Issues with VS Code on MAC/OS X and removed author-verification-requested Issues potentially verifiable by issue author labels Dec 7, 2020
@roblourens roblourens added the verified Verification succeeded label Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bpasero bpasero

Labels
bug Issue identified by VS Code Team member as probable bug insiders-released Patch has been released in VS Code Insiders linux Issues with VS Code on Linux macos Issues with VS Code on MAC/OS X verified Verification succeeded workbench-cli VS Code Command line issues
Projects
None yet
Milestone
November 2020
Development

Successfully merging a pull request may close this issue.

Correctly inherit/don't inherit the shell environment segevfiner/vscode
7 participants
@joaomoreno @roblourens @bpasero @weinand @rzhao271 @segevfiner and others