Could anyone tell me why this doesn't work?

{
    "roc-lang.language-server.exe": "${env:ROC_LANGUAGE_SERVER_PATH}",
    // If you'd like to format Roc files on save
    "editor.formatOnSave": true
}

This is in the workspace settings.json for a project. When I look at the plugin's output, it's treating that exact string as the path, rather than resolving it to the value of the environmental variable. A few other things to note:

1. If I instead use the literal string that is the value of the variable, it works fine.

2. I am able to echo that variable in vs code's terminal, so I know it's available.

3. I am on on linux with a reasonably recent version of vs code.

Thanks.

EDIT: Maybe this is just a limitation of the roc language plugin, that it isn't programmed to resolve the variable?

I am trying to override the default python interpreter for a specific workspace. I have created a .vscode directory in the folder with the following two files:

settings.json:

{
    "python.envFile": "${workspaceFolder}/.vscode/.env",
    "python.defaultInterpreterPath": "${env:MY_PYTHON_PATH}/bin/python",
}

.vscode/.env:

MY_PYTHON_PATH=/path/to/my/python/interpreter

But the python interpreter is actually getting set to /bin/python - which implies that ${env:MY_PYTHON_PATH} is just empty.

Any ideas what is going wrong here?

I have c_cpp_properties.json, launch.json, and tasks.json in my .vscode folder. There are some strings that I use common between them. Is there a way that I can define an environment variable then use it in all three files?

For instance, in c_cpp_properties.json I have:

"compilerPath": "/some/path/to/sysroots/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-g++"

In tasks.json I have:

"command": "/some/path/to/sysroots/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-g++ --sysroot=/some/path/to/sysroots/aarch64-xilinx-linux -g test.cpp -o build/test"

In launch.json I have:

"miDebuggerPath": "/some/path/to/sysroots/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-gdb"

I want to just define "${sysroots} = /some/path/to/sysroots" once, then just use that variable in all three files. That way if I have to change it, I only need to change it in one place. This seems like pretty obvious functionality. Am I missing something?

Hi, I already know how to set environment variables in launch.json.

What I can’t figure out is how to have it read environment variables from my shell. My AWS credentials get cycled a lot and I was to do something like

“env” : { AWS_SESSION_TOKEN: “${AWS_SESSION_TOKEN}”

So the debugger pulls the variables from the current shell. Is there any way to do that?

It’s not finding them currently and I’m losing my mind running thing without a debugger.

I'm trying to create a tasks.json and launch.json that multiple developers can share. This would require the commands invoked to be configurable by each user to point to the correct path for their dev environment. I'm envisioning a situation where each dev updates a toolchain file with a set of predefined variables that can then be used in the launch/task file.

We already do something similar for some of the plugins in the settings.json (ie. "cmake.cmakePath": "/usr/bin/cmake"), and I see that standard variables are supported in the tasks.json (https://vscode-docs.readthedocs.io/en/stable/editor/tasks/#variables-in-tasksjson). Is there some way that I can achieve calling "${my_tool_path}" in the task command, where my_tool_path is defined in some central location? Is there a more canonical way to accomplish what I am trying to do?

Using .Net 8.0.402 and Visual Studio Code 1.94.0

I'm trying to get pretty simply a value from a file named launch.json in .vscode folder. The path is:

.vscode\launch.json

and the path of the file I'm calling from is:

Program.cs

Program.cs has:

    private static void Main(string[] args)
    {
        string a = Environment.GetEnvironmentVariable("API_ENDPOINT");

And the launch.json has:
{
    "version": "0.2.0",
    "configurations": [
        {
...
            "env": {
                "API_ENDPOINT": "europe-west2-aiplatform.googleapis.com",

And string a gets a value of null. What's the correct way to receive it?

I feel like this is something very, very simple to solve.

Looking for some feedback from VS Code user community. We’re building a VS Code debugging extension for python and typescript. We need to add some environment variables to configure properties used by the extension.

We’re thinking of using the command palette to search for .env files and add our properties there for Python.

Is this best practice? What would folks here recommend for node apps?

I want to be able to set the env variable WORKON_HOME=path/to/venv and then open the workspace so that vscode will know about the venv. In the terminal is quite easy:

export WORKON_HOME=path/to/venv
code .

Would it be possible to save the env variable to the code-workspace, so that when I double click on it (or other GUI method), vscode will start knowing about it?

My OS is Windows and I usually work with cmake-based C projects. The compiler isn't always the same, it generally changes for each project.

I usually launch and configure the environment variables (PATH and others) of a terminal depending on the project I'm working on. I have terminal configuration for projects that need an instance of arm-gcc (installed in C:\nxp\toolchanins\... for example). Another terminal configuration for avr8-gcc and so on.

In this way cmake is able to find the correct compiler of the project (arm-gcc, avr-gcc or other) without putting any absolute path in the build configuration files (CMakeLists.txt, CMakePresets.json, ...).

I thought it was obvious to launch vscode from the same build terminal to have the same behaviour... and indeed it really works. However it works until I launch a second VSCode instance on a different compiler project. It seems the second VSCode instance inherit the same env variables from the first VSCode instance, ignoring the env variables of the terminal it was launched from.

The solution I found is to modify .vscode/settings.json, putting there the env variables needed for the workspace. In this case I need to use absolute paths, that isn't too good. And I need to specify the env variables multiple times in settings.json ("terminal.integrated.env.windows", "cmake.configureEnvironment" and so on).

Do you suggest another and better approach?

Hi All!

As I come up to speed on VS Code with Cmake Tools underneath I have had various problems of getting a key environment variable, VULKANK_SDK to be seen, particularly when processing the .vcxproj project file.

Assumptions going in

1. I launch a cmd window "Developer Command Prompt 2022"

2. I see VULKAN_SDK=C:\VulkanSDK\1.3.296.0

3. I enter code to bring Code

4. bash shell terminal shows:

echo $VULKAN_SDK

C:\VulkanSDK\1.3.296.0

Now when I use Command-Shift build I get the following message as an example.

```

error C1083: Cannot open include file: 'vulkan/vulkan.h': No such file or directory [C:\Users\fdemi\DevEnv\vulkan\VSCode\VulkanLearning\build\Vulkan_Tutorial.vcxproj]

(compiling source file '../Source/fdDevices/isDeviceSuitable.cpp')

```

So, when VsCode executes Cmake which processes Vulkan_Tutorial.vscproj the VULKAN_SDK environment variable is not seen when parsing the .vcxproj file. My Vulkan_Tutorial.vcxproj file contains:

```

<AdditionalIncludeDirectories>%VULKAN_SDK%\Include;C:\Program Files\Microsoft Visual Studio\2022\Community\Libraries\glfw-3.4.bin.WIN64\include;C:\Program Files\Microsoft Visual Studio\2022\Community\Libraries\glm-1.0.1;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>

```

I in the past I managed to hack my way around a problem like this. However, what it was a terrible idea. So there are elements of the environment that I don't fully understand.

I do understand the setting have a hierarchy of User , Workspace , and folder. I'm not sure exactly where in that hierarchy the .vscode/c_cpp_properties.json and .vscode/settings files are.

I imagine that .vscode/settings is folder settings mentioned third in the above and could cause collisions with the other settings file.

The primary problem for me is the building, secondary is settings for flylint and other C++ tools.

easily picked In the past I used cmake converter to move from Visual Studio which was a pain.

Thanks,

Frank