Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

Don't write to settings.json #9

Open
Tyriar opened this issue Feb 7, 2022 · 3 comments
Open

Don't write to settings.json #9

Tyriar opened this issue Feb 7, 2022 · 3 comments

Comments

@Tyriar
Copy link
Contributor

Tyriar commented Feb 7, 2022

I see this is written to user settings from the extension:

  "terminal.integrated.env.osx": {
    "FIG_NEW_SESSION": "1"
  },

I find this a little invasive, can you do without this information? Can your integration scripts set this instead?

There should soon be a way to reliably inject environment variables on macOS with microsoft/vscode#99878, this is an existing feature but it has some problems at the moment due to how path_helper works.

@Tyriar
Copy link
Contributor Author

Tyriar commented Jun 1, 2022

@mschrage thoughts here? If you just want to know if it's VS Code you can check if $TERM_PROGRAM is vscode. It's frustrating having settings edited implicitly by extensions like this.

@mschrage
Copy link
Member

mschrage commented Jun 1, 2022

Hey @Tyriar - we add the FIG_NEW_SESSION environment variable to handle the case where users launch VSCode using the code CLI.

Without this workaround, the integrated terminal inherits the environment from the parent terminal session (including all of the environment variables indicating that Fig's shell integration has been setup already). This results in the shell integration to not be configured correctly.

We check for the existence of the FIG_NEW_SESSION variable as a signal to force the shell integration to be setup regardless of other environment variables.

Will the VSCode integrated terminal always have $TERM_PROGRAM set to vscode? What about if the inheritEnv setting is enabled?

@Tyriar
Copy link
Contributor Author

Tyriar commented Jun 1, 2022

So you currently check $FIG_NEW_SESSION and then set it to 0 or unset it after?

Yes $TERM_PROGRAM is always set when you create a shell in vscode, regardless of the inheritEnv setting. The one exception here is if the terminal was launched with a strictEnv flag which is a seldom used extension API we added for the Windows team and I wouldn't worry about that case, additionally strictEnv terminals don't add variables from terminal.integrated.env.osx anyway.

All terminals will also be inherited from the same original shared environment of the electron main process (or the same inheritEnv: false environment), no matter where you run code from, so I think $TERM_PROGRAM should work.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants