I am following the walkthrough from the microsoft docs for using typescript in a vs code project. When I try and run the build task, the terminal comes up with
Executing task: c:\whatever\my path with spaces\Projects\ProjectName\node_modules.bin\tsc.cmd -p "c:\whatever\my path with spaces\Projects\ProjectName\tsconfig.json"
and the error
'c:\whatever\my' is not recognized as an internal or external command,
That is, the space in the folder name is confusing the task runner. I need something like
call "c:\whatever\my path with spaces\Projects\ProjectName\node_modules\.bin\tsc.cmd" -p "c:\whatever\my path with spaces\Projects\ProjectName\tsconfig.json"
How do I set up VS Code so the terminal recieves an input it can interpret with spaces in the directory name? Thank you
current tasks.json:
"version": "2.0.0",
"tasks": [
{
"type": "typescript",
"tsconfig": "tsconfig.json",
"problemMatcher": [
"$tsc"
],
"group": {
"kind": "build",
"isDefault": true
}
}
]
Try using ''-s to escape the string containing the spaces:
in terminal: c:\whatever\'my path with
spaces'\Projects\ProjectName\tsconfig.json
in .json: "command":
"c:\\whatever\\'my path with
spaces'\\Projects\\ProjectName\\tsconfig.json"
You should use quotation marks \" (slash + quotation mark) for the entire command as in
"command": "\"c:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/cl.exe\"",
Related
I'm running VSCode 1.54.3 on Windows10 along with Ubuntu in WSL.
This is the task I'm trying to build.
{
"label": "Verilog: Compile iVerilog File ",
"command": "iverilog",
"type": "shell",
"args": [
"-t vvp",
"-o ${fileBasename}.vvp",
"-l /opt/Xilinx/14.7/ISE_DS/ISE/DCM_SP.v",
"-I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/unisims",
"-I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/XilinxCoreLib/",
"wslpath ${workspaceFolder}${pathSeparator}${relativeFileDirname}${pathSeparator}${fileBasenameNoExtension}.v"
],
"problemMatcher": [
"$tsc"
],
"presentation": {
"reveal": "always"
},
"group": "build"
}
Clearly I'm here because it doesn't work so I'm here to throw myself at the feet of smarter people.
This is what it actually runs
> Executing task in folder xilinx_projects: iverilog '-t vvp' '-o pulse2.v.vvp' '-l /opt/Xilinx/14.7/ISE_DS/ISE/DCM_SP.v' '-I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/unisims' '-I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/XilinxCoreLib/' 'wslpath C:\demand\xilinx_projects\pulse2\pulse2.v
I've been to the following pages for help:
Single quotes not escaped in debug commands #91578
how-do-i-use-bash-on-ubuntu-on-windows-wsl-for-my-vs-code-terminal
Regression: WSL Shell Task command containing spaces fails
Paths separators in build config being escaped/stripped out prior to build command being run #35593
All double quotes removed from command in tasks.json in powershell #72039
Variable Reference
And of course: Integrate with External Tools via Tasks
I see other people struggling with it. I can't tell if that is current. These things find a way dead ending when someone finally gets it or the problem goes away from some other feature that I must not know about.
I'm sure the answer is somewhere in those links. I just can't find one that works for me. I've tried all kinds of variations of escape characters and none work for me.
You'll also see that the final argument is obscene compared to what someone that knows what they are doing would use. That same command works in "command":, but not as an arg.
I try to avoid asking questions but this is killing me. I fill very close to being able to use tasks to do more but I find the documentation incomplete and without examples of what the shell sees.
You can probably see what I'm trying to accomplish. Can you offer any advice on how to do this as painlessly as possible?
From the "containing spaces fails" issue that you linked to, I wasn't able to get the original version of the sample "My Task" to work, so it almost does seem like the fixed regression has regressed again. Either that, or the new 2.0.0 task system doesn't parse it the same way.
That example used one long "command", but specified the "executable" as wsl.exe. Something else may have changed here, because reading the ${env:windir} as specified there doesn't work for me either when launching vscode from WSL. But no matter, I'm just going to leave off the path for now.
One alternative presented there was to specify each element as a separate arg (i.e. "args": [ "ls", "/", "&&", "echo", "OK", "#", "comment" ]). That does work for me, and your iverilog arguments seem to work when parsed that way as well. At least, it comes out as an unquoted command line. To be honest, the way the "Quoting" section of the Tasks doc reads, it sounds like that is the expected way to do it -- Have each element be a separate "arg". From that page:
If a command and arguments are provided, the task system will use single quotes if the command or arguments contain spaces.
That's exactly what we are seeing, of course.
But there's another alternative I found, as well. A comment further down that thread mentioned passing -c to the (old) ubuntu1804.exe executable. That led me to try something similar for the wsl.exe command, and it worked to pass in args of "-e", "sh", and "-c", along with the full commandline in the "command", like so:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "Verilog: Compile iVerilog File",
"options": {
"shell": {
"executable": "wsl.exe",
"args": [
"-e"
"sh",
"-c"
]
}
},
"type": "shell",
"command": "iverilog -t vvp -o ${fileBasename}.vvp -l /opt/Xilinx/14.7/ISE_DS/ISE/DCM_SP.v -I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/unisims -I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/XilinxCoreLib/ wslpath ${workspaceFolder}${pathSeparator}${relativeFileDirname}${pathSeparator}${fileBasenameNoExtension}.v",
"problemMatcher": [
"$tsc"
],
"presentation": {
"reveal": "always"
},
"group": "build"
},
{
"label": "My Task",
"options": {
"shell": {
"executable": "wsl.exe",
"args": [
"-e",
"sh",
"-c"
]
}
},
"type": "shell",
"command": "ls / && echo OK # comment",
"problemMatcher": [],
"presentation": {
"reveal": "always"
},
"group": "build"
}
]
}
I believe that's your consolidated full command-line for iverilog. I've also included the "My Task" example, which is generic enough that it should work on any WSL system.
Can you replace corresponding setion of tasks.json with this ?
"type": "shell",
"command": "wsl",
"args": ["bash", "-c", "iverilog\
-t vvp -o ${fileBasename}.vvp -l /opt/Xilinx/14.7/ISE_DS/ISE/DCM_SP.v\
-I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/unisims\
-I /opt/Xilinx/14.7/ISE_DS/ISE/verilog/src/XilinxCoreLib/\
$(wslpath '${workspaceFolder}${pathSeparator}${relativeFileDirname}${pathSeparator}${fileBasenameNoExtension}.v')"]
I am trying to create a build task to quickly deal with building the project. However, I am not able to cd into the project directory to execute the makefile containing the commands.
{
"version": "2.0.0",
"tasks": [
{
"label": "Build",
"type": "shell",
"command": "cd /path/to/folder; make build",
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
Error message:
The terminal process terminated with exit code: 1
Even just the cd command gives the same error. Running pwd instead shows that I am in root /.
Am I missing something. Couldn't find any help on web search.
Environment:
- Windows 10
- I have WSL installed
EDIT:
Tried setting
"options": {
"cwd": "${fileDirname}/.."
}
fileDirname was pointing to the .vscode folder inside my project folder, so thought .. from it would work. But pwd still show it is in root.
I want to setup VScode so I can use build tasks to build my project. The project is build using make, en I have defined a build task that runs make. However, before running make, I normally would source a script that sets my environment variables correctly. If I add a new build task with the source command, and set my main build tasks to first execute the source command, the environment variables are not propagated properly. How can I make sure the enviroment variables are kept between build tasks?
My tasks.json file:
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "shell",
"label": "make",
"command": "make",
"args": [],
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
},
"dependsOn": "Set environment"
},
{
"label": "Set environment",
"type": "shell",
"command": "source path/to/source_me.sh",
"group": "build",
]
}
Not in this way. Sourcing a file is injecting file contents into current shell session, which ends as soon as the task ends. The make task is run in a separate shell session, so these two do not interact. You may try to do a single task that executes a single line: source path/to/source_me.sh && make.
I solved my problem like this:
"tasks": [
{
"label": "all",
"type": "shell",
**"command": "source gitenv.sh && cd ${fileDirname} && alfred all"**,
"problemMatcher": [],
"group": {
"kind": "build",
"isDefault": true
}
}
]
Where alfred is a macro for make command with extra args.
${fileDirname} returns a current directory in which you have open file.
So if you open a file and in the same directory you have Makefile you can CTRL + SHIFT + B to execute this default task.
I want to create a VS-Code task, that executs a R command to convert markdown into PDF. My current task looks like this:
{
"label": "rmarkdown -> pdf",
"type": "process",
"command": "Rscript",
"args": ["-e", "\"rmarkdown::render('${file}', 'pdf_document')\""],
"windows": true,
"presentation": {
"reveal": "always",
"panel": "new"
}
}
The problem ist, that ${file} returns a path like this:
d:\data\documents\myFile.md
but R needs a path with escaped backslashs like this:
d:\\data\\documents\\myFile.md
how to get a escaped path from ${file}?
Alternative a path with normal slashs will do the job as well, because R will automaticaly replace / to \\.
VSCode is designed to return paths with platform-specific separators.
As a typical workaround, you can create an intermediate script that will condition arguments passed into it from a task and then call your tool.
Relevant discussion in vscode issue tracker: #70050.
I'm trying to setup visual studio code for rust to do debugging. In my launch.json file I have
{
"version": "0.2.0",
"configurations": [
{
"name": "(Windows) Launch",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceRoot}/target/debug/vscode-rust-debug-example.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": true,
"preLaunchTask": "localcargobuildtask"
}
]
}
and in my tasks.json I have
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "localcargobuildtask",
"command": "echo hi",
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
Where "echo hi" is in my tasks I eventually want to have something like "cargo build" or "cargo test" or whatever. But this is just a starting step.
But when I press F5 the output I get is
> Executing task: C:\programs\VSCodeWorkspaces\RustProjects\vscode-rust-debug-example-debug-config-included\echo hi <
The terminal process terminated with exit code: 2
Terminal will be reused by tasks, press any key to close it.
Rather than running "echo" from where ever the terminal finds it (working directory first, then check global path variable like you would expect) it is actually looking for a program named "echo" in my root folder of the workspace.
How do I tell visual studio code "No I don't want you to run workspace/echo, I want you to run echo in workspace" ? Or is there another more direct way to tell visual studio code "compile this before you debug it" ?
The answer to this question How to debug Rust unit tests on Windows?
suggests that changing
"command": "cargo build",
into
"command": "cargo",
"args": [
"build"
],
in the tasks.json file works and somehow it does. Maybe the editor is configured to search the %path% for single word commands, or maybe some plugin I installed overwrote the "cargo" command. Maybe the reason echo wasn't found is because it is a terminal command, not a program. Maybe the error message was a lie and it was only reporting that it couldn't find workspacefolder\command despite checking %path%? Or maybe none of that. I have no idea. It is some pretty idiosyncratic behavior.