In my devcontainer.json for vscode, I am trying to load in a build variable. This variable is on my local machine's environment, my code looks like the following:
//build arguments
"build": {
"args": {
"TOKEN": "${localEnv:TOKEN}"
}
}
It seems like it works when I put in a direct string, or something like "${localEnv:HOME}", but it is not picking up this custom one. which is strange because I can do 'printenv TOKEN' and it prints out correctly.
any ideas on what I may be doing wrong?
Add your export BLA=1 to .profile, this was the only way VScode was able to pass through env variables to the devcontainer.
.devcontainer:
{
"name": "devcontainer",
"build": {
"dockerfile": "${localWorkspaceFolder}/Dockerfile",
"context": "${localWorkspaceFolder}",
},
"remoteEnv": {
"FOO": "${localEnv:FOO}",
"BAR": "${localEnv:BAR}",
}
}
First, ensure that you have the VS Code Terminal -> Integrated: Inherit Env setting set to true. This is described on the Advanced Container Configuration page:
Workarounds
If that doesn't fix your problem (it didn't for me), here are some of the workarounds that I have found:
Set the variables in your ~/.bashrc file (or export them temporarily in the terminal) and start VS Code from a bash prompt (the executable is code).
$ export TOKEN=tokenvalue
$ code
Set the variables in your ~/.pam_environment file (these are available session wide and are inherited by applications started with the launcher). You will need to logout and login or reboot for these to apply.
TOKEN=tokenvalue
Set the environment variables in one of your VS Code settings files (user or workspace) using the Terminal -> Integrated Env: Linux setting:
// Object with environment variables that will be added to the VS Code process to be used by the terminal on Linux. Set to `null` to delete the environment variable.
"terminal.integrated.env.linux": {
"TOKEN": "tokenvalue"
},
Related
we are using cobol now, but this config error keeps on appearing and I do not know how to fix this thing. Any help would really mean alot. (Just a beginner and trying to learn vscode)
Late, but perhaps worth it. Currently there is a cobenv.bat or .sh (if you are on linux). The whole path to the file may differ for me is this:
C:\msys64\mingw64\bin\cobenv.cmd
You'll notice that if you execute the file and run the compiler everything works fine, but once you close that bash the error shows up again.
That's because the scope of those variables was just that session. You may execute it every time you run the compiler or you can make those variables to persist on your system. In my case I did the later, modifying cobenv.cmd
But not those lines with the variable PATH.
So this lines, i.e., whenever we encounter this same three variables. For instance, after a certain if in that file we encounter:
setx "COB_LIBRARY_PATH" "%MINGW_ROOT_PATH%lib\gnucobol%COB_LIBRARY_PATH%"
setx "COB_COPY_DIR" "%MINGW_ROOT_PATH%share\gnucobol\copy"
setx "COB_CONFIG_DIR" "%MINGW_ROOT_PATH%share\gnucobol\config"
Default value: set.
New value: setx.
Delete the = to comply with the correct syntax. Check the compiler with different new session.
This message is only presented in vscode's Terminal after you've entered a command there, it is actually not related to vscode.
The "common" way with vscode would be to create a vscode task for the compilation and configure a problem matcher, too, so vscode is able to parse the messages. For details see vscode docs "Integrate with External Tools via Tasks".
As the message is coming from the GnuCOBOL compiler it may be reasonable to check in its discussion board, which also includes a note how to use your setup of vscode with GnuCOBOL MinGW package, this would be your starting point, assuming D:\COBOL is the place where you have your sources (and this is the alos the workspaceFolder as in your screenshot), D:\COBOL\copy where your copybook reside and D:\GnuCOBOL where the MinGW package is:
{
"version": "2.0.0",
"tasks": [
{
"label": "GnuCOBOL - cobc (compile single file)",
"type": "shell",
"command": "cobc",
"args": [
"-I${workspaceFolder}\\copy",
"${file}"
],
"problemMatcher": "$gnucobol3-cobc",
"options": {
"env": {
"COB_CFLAGS": "-I\"D:\\GnuCOBOL\\include\"",
"COB_CONFIG_DIR": "D:\\GnuCOBOL\\config",
"COB_COPY_DIR": "D:\\GnuCOBOL\\copy",
"COB_LDFLAGS": "-L\"D:\\GnuCOBOL\\lib\"",
"COB_LIBRARY_PATH": "D:\\GnuCOBOL\\extras",
"PATH": "D:\\GnuCOBOL\\bin:${env:PATH}"
}
},
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
Instead of directly calling cobc you could also call cobc.bat or similar, then create it with all your default options set there (or, if you use the official mingw packages, just call the set_env.cmd) then call the compiler.
Concerning "how to fix that message" - make sure you have the "config" directory of GnuCOBOL and have COB_CONFIG_DIR set to it either in the task definition or outside of vscode (for example by starting vscode from the "Developer prompt for GnuCOBOL MinGW" (which is the set_env.cmd distributed with it).
How do I delete the custom profile "New 1" as shown in the picture?
I'm using Zsh, so I suggest configuration
"terminal.integrated.profiles.osx": {
"zsh": {
"path": "/bin/zsh",
"icon": "star",
"env": {
"TESTING_VAR": "abc"
}
}
},
"terminal.integrated.defaultProfile.osx": "zsh",
As described in the Configuring profiles section of the VS Code docs), when you create a custom terminal profile, it adds an entry to your settings.json file:
The recommended way to create a new profile is to run the Terminal: Select Default Profile command and activate the configure button on the right side of the shell to base it on. This will add a new entry to your settings that can be tweaked manually in your settings.json file.
...
"terminal.integrated.profiles.windows": {
"PowerShell -NoProfile": {
"source": "PowerShell",
"args": ["-NoProfile"]
}
},
"terminal.integrated.profiles.linux": {
"zsh (login)": {
"path": "zsh",
"args": ["-l"]
}
}
So open your User settings and you'll find the terminal.integrated.profiles.<OS> setting with an added entry for your custom profile under your corresponding OS. It is better to open the settings.json file directly, or open it from the UI "Edit settings.json":
settings UI
settings.json
"terminal.integrated.profiles.osx": {
"1": {
"path": "bash"
}
}
(I'm using a Mac OS so I have it in .osx. It gets added correspondingly to .linux or .windows)
To remove your custom profile:
Simply delete your custom profile ("1": {...}) from terminal.integrated.profiles
Reload/Restart VS Code
When VS Code reloads/restarts, the removed custom profiles should be gone. (It seems these custom profiles are read and loaded one-time during VS Code startup).
Note though that this only works for custom profiles. For built-in profiles, you'll have to set the profile to null instead:
To remove profile entries from the dropdown, set the name of the profile to null. For example, to remove the Git Bash profile on Windows, use this setting:
"terminal.integrated.profiles.windows": {
"Git Bash": null
}
I can run python files in cmd promt and Vscode terminal (cmd prompt). When I try to run any programme with Code runner ("code-runner.runInTerminal": false), I get the following error:
[Running] python "c:\Users\MY PATH INCLUDING WHITESPACE\hello_world.py"
Python was not found but can be installed from the Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640
Here are the user settings (settings.json) I have tried:
"code-runner.executorMap": {
"python": "python",
},
"code-runner.executorMap": {
"python": "$pythonPath $fullFileName",
},
"code-runner.executorMap": {
"python": "$pythonPath -u $fullFileName",
},
..but I always get the same error.
It seems like the problem could be related to code runner, but could have something to do with the setup of python on my machine.
It could potentially have something to do with the fact I have two python files for the location of python.exe:
(base) C:\>where python
C:\Users\<user_name>\AppData\Local\Continuum\anaconda3\python.exe
C:\Users\<user_name>\AppData\Local\Microsoft\WindowsApps\python.exe
This is the only difference I can think of to another machine where this actually works, but can't be sure.
Any ideas what the issue could be?
maybe try the following:
Change the executormap to:
"code-runner.executorMap": {
"python": "\"$pythonPath\" $fullFileName",
}
Also you could try to give a concrete python path, maybe create a venv and try there:
"python.pythonPath": "venv/bin/python"
If your directory tree has spaces - do this:
"code-runner.executorMap": {
"python": "\"$pythonPath\" -u $fullFileName",
}
This is in the case were the "python.pythonPath": "C:\Users\Documents and Settings\appdata\python\code\something something\script.py"
Spaces in the directory structure will abort the script and you'll get a response something like:
"C:\Users\Documents is not a valid directory."
So you need the escape character like someone above explained.
In order to define my environment variables in a single place a configured a task in which a run a shell script. The task is run as preLaunchTask in my launch.json.
In my launch.json I now try to reference the environment variables I configured in the script (like export AWS_REGION="eu-west-1").
The launch.json looks as follows:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
//..
"env": {
//"AWS_REGION": "us-east-1", //works
"AWS_REGION": "${env:AWS_REGION}", //doesn't work, why?
},
"args": [],
"preLaunchTask": "setupEnv",
}
] }
Doesn't work, why?
According to this post from user weinand...
The ".env" file is read and processed after VS Code has substituted
variables in the launch config. So your debugged program will indeed
see the environment variable "FOO" with the correct value but VS
Code's variable substitution in the launch.json will not see it.
The reason for this is that ".env" files are a node.js concept and not
a generic platform mechanism. So VS Code does not know anything about
.env files, but the node.js debugger knows about .env files.
... this functionality in launch.json is specific for applications running on Node.js, although that's not what M$ explains in their documentations for VSCode.
Possible solution
For Python applications (possibly for other platforms as well) environment variables defined in a .env file (or whatever name you like) will be available for your application as long as the following configuration is present in launch.json...
{
"version": "0.2.0",
"configurations": [
{
[...]
"envFile": "${workspaceFolder}/.env", // Path to the ".env" file.
[...]
}
]
}
Note that just exporting a variable...
export SOMEVAR_A=1234
... will not make the environment variable SOMEVAR_A available for the application being executed by the VSCode debugger nor for the settings - especially inside "env" and "args" ("configurations") - in launch.json as, for example, in this case...
{
"version": "0.2.0",
"configurations": [
{
[...]
"env": {
"SOMEVAR_A": "${env:SOMEVAR_A}"
},
"args": [
"${env:SOMEVAR_A}"
]
[...]
}
]
}
NOTE: In our tests the ${env:SOMEVAR_A} syntax did not work in any scenario. That is, didn't work for the application ("env") and didn't work for the settings ("args") in launch.json.
PLUS I: Dirt Hack
For values present in "args" ("configurations") you can use the hack below...
{
"version": "0.2.0",
"configurations": [
{
[...]
"envFile": "${workspaceFolder}/.env",
"args": [
"`source \"${workspaceFolder}/.env\";echo ${SOMEVAR_A}`"
]
[...]
}
]
}
... as the configuration in "envFile" doesn't work.
Notice, although, that the following construction...
[...]
"args": [
"`echo ${SOMEVAR_A}`"
]
[...]
... would also work for "args" as long as the environment variable "SOMEVAR_A" has been previously exported in the conventional way.
The same reasoning would work for a tasks (tasks.json), but in both cases we can't guarantee that.
TIP: An .env File Example
SOMEVAR_A="abcd"
SOMEVAR_B="efgh"
SOMEVAR_C=123456
PLUS II: Export Variables
There are cases where you will need to export variables (eg. export SOMEVAR_A="abcd") so that they can be consumed by certain resources. In these cases there may be problems, because the fact that we export variables prevents (we don't know why) that they are seen in the context of the "envFile" configuration "envFile": "${workspaceFolder}/.env".
A workaround to get around these limitations is to add set -a before the variables set and set +a after it. With this we were able to meet the two scenarios as this example...
#!/usr/bin/env bash
set -a
SOMEVAR_A="abcd"
SOMEVAR_B="efgh"
SOMEVAR_C=123456
set +a
... or in a more compatible and safe way use set -a/set +a as in this example...
[...]
"args": [
"`set -a;source \"${workspaceFolder}/.env\";set +a;echo ${SOMEVAR_A}`"
[...]
VSCode's support for environment variables is a mess! 🙄
Conclusion
We don't know if the limitations we are dealing with here are from VSCode's own design or are bugs. Anyway, it doesn't seem to make much sense.
These procedures were tested on Manjaro Linux (Arch based).
Thanks! 🤗
[Ref(s).: https://unix.stackexchange.com/a/79077/61742 , https://stackoverflow.com/a/30969768/3223785 ]
Looking at the issue comment quoted below, it seems this is currently not possible.
${env:...} only expands environment variables that were set in the parent shell that ran code. It doesn't expand variables set in the tasks.json env options.
https://github.com/Microsoft/vscode/issues/47985#issuecomment-460678885
It doesn't work as Eduardo Lucio stated. Here is some alternative that works at least on my case that sometimes uses env.sh file to load the environment variables and require .env file for VsCode debugging in Go project. To launch the application normally, load the env using commmand $ source env.sh. On this case, you want to load .env file instead.
Env-Example: Linux/WSL2
If the .sh is what I tought of, probably just some line of export commands: env.sh
export DBUrl="sql-connection-string-here"
export DBPass="somedbpass"
Create the prelaunch task to generate the .env file .vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "buildenv",
"command": "sed",
"args": ["s/export //g", "local_env.sh", ">", ".env"],
"type": "shell"
}
]
}
you can see that it calls sed to replace any export with empty string and rewrites a .env file.
On .vscode/launch.json, load the preLaunchTask and change the target envFile to the generated file:
{
"version": "0.2.0",
"configurations": [
{
"name": "My App Debug",
"type": "go",
"request": "launch",
"mode": "debug",
"program": "${workspaceFolder}",
"preLaunchTask": "buildenv",
"envFile": "${workspaceFolder}/.env",
}
]
}
Now, everytime VsCode run the debugger, it generates .env file and only need to maintain single env.sh file.
Reference: https://stackoverflow.com/a/38746951/12325366
I installed the Run On Save extension for VS Code. I made a Workspace setting for it, and if I change a file then resave, it does not seem to run. "I run for all files" does not show up in the console or terminal.
When I chose to edit the command configuration in my Workspace settings, it automatically edited the file with the comment "Place your settings in this file to overwrite default and user settings." so it looks like this:
// Place your settings in this file to overwrite default and user settings.
{
"editor.mouseWheelZoom": false,
"emeraldwalk.runonsave": {
"commands": [
{
"match": ".*",
"isAsync": true,
"cmd": "echo 'I run for all files'"
}
]
}
}
I'm new to configuring Workspace settings, so I'm not sure if this is okay or not. I ensured that Run On Save is enabled by selecting it on the command palette.
Here is the site for the extension: https://marketplace.visualstudio.com/items?itemName=emeraldwalk.RunOnSave
In order to see the console output, you have to be in the Output tab and select the Run On Save option in the dropdown. The extension was created before the integrated terminal existed and hasn't seen a major update in a while.
Regarding the comment that was added to your config:
// Place your settings in this file to overwrite default and user
settings.
is unrelated to this particular extension. It is just vscode letting you know the purpose of the workspace level configuration. It allows you to override a subset of your more global user / default settings. This allows you to keep reasonable default preferences but to customize certain specific things in any given workspace.
Regarding the original RunOnSave extension, feel free to file an issue here https://github.com/emeraldwalk/vscode-runonsave/issues if you have any questions or problems. I would also welcome pull requests if anyone is interested.
I had the exact same issue. I removed that extension and am using this one instead:
https://marketplace.visualstudio.com/items?itemName=wk-j.save-and-run
It is a fork based on RunOnSave. This one works for me when I set its configuration in my user settings and then run the command "Save and Run: Enable".
This one uses the bulit-in powershell terminal.
HTH
In addition to our dear #bingles, I have accidentally discovered that the commands should be added to .vscode/settings.json file instead of .vscode/emeraldwalk.runonsave as said in the plugin documentation
Add it to settings.json and everything should work as expected.
For the extension to work on Workspace you must put the emeraldwalk.runonsave inside settings:
{
"settings": {
"emeraldwalk.runonsave": {
"commands": [
{
"match": ".*",
"isAsync": true,
"cmd": "echo 'I run for all files'"
}
]
}
}
}
A related one:
Previously I used RunOnSave, this time around I used Code Runner.
Code Runner - https://marketplace.visualstudio.com/items?itemName=formulahendry.code-runner
Below are it's settings I used:
File: %AppData%\Code\User\keybindings.json
{
{
"key": "ctrl+s",
"command": "code-runner.run"
}
}
File: .vscode\settings.json
{
"code-runner.saveFileBeforeRun": true,
"editor.codeActionsOnSave": [
"code-runner.executorMap"
]
"code-runner.executorMap": {
"javascript": "node a.js"
},
}
If possible, you could use Code Runner with the above settings, or use a similar to the above settings for the RunOnSave.
Note that RunOnSave has its own tab which is time-consuming to switch to another tab.
With Code Runner I can see the output in the Output tab itself which is a very nice thing, saves time.