How to fix vscode GnuCOBOL setup "configuration error: default.conf: No such file or directory" - visual-studio-code

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).

Related

How to Debug Amplify JavaScript functions in VS Code

How can I debug Amplify JavaScript functions on VS Code on Windows 10?
This issue came up on github under How to debug amplify function using visual studio code during invocation?, but it's closed and quite old. For example, amplify invoke function is deprecated in favor of amplify mock function.
I've tried this launch.config:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Create Reort",
"type": "node",
"request": "launch",
"program": "${env:APPDATA}/npm/node_modules/#aws-amplify/cli/bin/amplify",
"args": [
"mock",
"function",
"sayhello",
"--event",
"src/event.json",
"--timeout",
"0"
],
"console": "integratedTerminal"
}
]
}
Which will log the output, but doesn't hit any breakpoints inside the function being executed:
Setup steps:
Install amplify cli
npm install -g #aws-amplify/cli
Initialize amplify. Choose JavaScript with any framework.
amplify init
# Choose your default editor: Visual Studio Code
# Choose the type of app that you're building: javascript
# What javascript framework are you using: none
Add function
amplify add function SayHello
# Choose the runtime that you want to use: NodeJS
# Choose the function template that you want to use: Hello World
Here's a kinda hacky workaround.
As far as I can tell there isn't that much magic to lambdas for a single execution (The special sauce in the runtime environment, event handling, and auto scalability). The Amplify CLI passes in the event object from event.json and calls the function defined as the handler. You can do that in vanilla node js as well.
Create a file like debug.js - you can put it anywhere you want, but mine is in the .vscode directory
const { handler } = require("../amplify/backend/function/sayHello/src")
const event = require("../amplify/backend/function/sayHello/src/event.json")
(async function(){
// invoke
const response = await handler(event)
console.log(response)
})()
Then you can use a normal node js debug launch configuration like this:
{
"name": "Debug Function",
"program": "${workspaceFolder}/.vscode/debug.js",
"request": "launch",
"skipFiles": ["<node_internals>/**"],
"type": "pwa-node"
}
Something a little friendlier / out-of-the-box would be nice, but this at least allows step through debugging without too much extra work.
This used to work in an older version of VS Code. I opened https://github.com/aws-amplify/amplify-cli/issues/6894 to hopefully address the issue.
Meanwhile, here's another hacky workaround suggested here that uses Node's injector. Add this code to the top of your handler method (making sure you remove it before committing):
require('inspector').open(9229, '127.0.0.1', true);
debugger;
Be sure to set a long enough timeout in the amplify mock command in launch.json. To step through the code, you can use Chrome's Node debugger by navigating to about:inspect and clicking on "Open dedicated DevTools for Node".

problem loading in ${localEnv:TOKEN} into devcontainer.json

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"
},

Launch.json: how to reference an environment variable

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

Node debugging, make `${file}` dynamic?

With the right debug config file I can make VSCode run the currently focussed file through Mocha. However, I find it frustrating that if I am working on the actual code, rather than the spec file and I press F5, it tries to run the actual code as a spec file through Mocha.
So, my question is; given a file structure like this:
Folder
File.js
File.spec.js
And a debug config (.vscode/launch.json) like this:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Unit Tests: Current File",
"program": "${workspaceRoot}/node_modules/.bin/_mocha",
"cwd": "${workspaceRoot}",
"args": [
"-u", "tdd",
"--timeout=999999",
"--colors",
"--opts", "${workspaceRoot}/mocha.opts",
"${file}" // I want to make this dynamic
],
}
]
}
Is it possible to get VSCode to debug the spec file whether the spec file (File.spec.js) or it's subject (File.js) are selected?
You can introduce a new dynamic variable by writing a simple extension that just defines one command, e.g. a smartFile command.
Then you can refer to that command in your launch config as ${command:smartFile}.
For the implementation of the command you can use everything available in VS Code extension API. So you can not only calculate a path based on your folder structure, but you can even pop-up UI. E.g. you could use QuickPick to select a test case from the list of all tests.

Visual Studio Code Run On Save Extension not running

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.