Extension|Author (truncated)|Version
---|---|---
gitignore|cod|0.5.0
vscode-markdownlint|Dav|0.11.0
vscode-eslint|dba|1.4.3
tslint|eg2|1.0.21
vscode-npm-script|eg2|0.3.3
php-debug|fel|1.11.1
php-intellisense|fel|1.5.4
php-pack|fel|1.0.1
fontsize-shortcuts|fos|1.4.0
explorer-excluded-files|sad|1.0.0
ignore-gitignore|stu|1.0.1
terminal-tabs|Tyr|0.1.1
(1 theme extensions excluded)
Steps to Reproduce:
"terminal.integrated.shell.windows": "PATH\\TO\\BASH\\FOR\\WINDOWS\\bash.exe",
"terminal.integrated.shellArgs.windows": [
"--login",
"-i"
],
tsc: task from the Tasks > Run Task menu. The output in the console will be the following: (The project folder name is f:\repos\public\docs_gm\ and local tsc IS installed from npm)> Executing task: f:\repos\public\docs_gm\node_modules\.bin\tsc.cmd --watch -p "f:\repos\public\docs_gm\tsconfig.json" <
bash: f:repospublicdocs_gmnode_modules.bintsc.cmd: command not found
The terminal process terminated with exit code: 127
Terminal will be reused by tasks, press any key to close it.
Reproduces without extensions: Yes
I think this is probably a support problem with tsc not working with git bash
I'm affected by this bug as well. We use the tsc: watch task to monitor TypeScript changes. My current work around is to open git bash and run tsc -w to start my watcher. That works regardless of what version of the TypeScript compiler and Git for Windows I have installed.
We recently updated our tasks.json file to version: 2.0 schema using the default options for tsc: watch, which generated the following tasks.json file:
{
"version": "2.0.0",
"tasks": [
{
"type": "typescript",
"tsconfig": "tsconfig.json",
"option": "watch",
"problemMatcher": [
"$tsc-watch"
],
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
The that task works for my coworkers with CMD configured, but doesn't for me (since I use Git Bash).
However, when I backdate the tasks.json file to our previous version (below), the watcher build task starts as expected.
"version": "0.1.0",
"tasks": [
{
"taskName": "tsc watch",
"command": "tsc",
"isShellCommand": true,
"args": ["-w", "-p", "."],
"showOutput": "silent",
"isBackground": true,
"isBuildCommand": true,
"problemMatcher": "$tsc-watch"
}
]
I expected the two tasks to have roughly equivalent behavior to them (fire up the watcher and monitor my changes). Is there a change I should make to our build task to support using Bash in VSCode on Windows?
This is the same problem as with WSL. The underlying reason is that the pathes need / instead of and a special starting sequence. When run under Windows task assume a Windows terminal.
I have a similar issue. When the integrated terminal is configured to use bash,
"terminal.integrated.shell.windows": "C:\Program Files\\Git\\bin\\bash.exe"
the default typescript build task v 2.0.0
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "typescript",
"tsconfig": "tsconfig.json",
"problemMatcher": [
"$tsc"
],
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"reveal": "silent",
"panel": "dedicated"
}
}
]
}
`
tries to re-use this bash-based terminal while running the Windows tsc command:
Executing task: e:_Dev_Prototypes2017_WEBgika-webservernode_modules.bintsc.cmd -p "e:_Dev_Prototypes2017_WEBgika-webservertsconfig.json" <
/usr/bin/bash: e:_Dev_Prototypes2017_WEBgika-webservernode_modules.bintsc.cmd: command not found
The terminal process terminated with exit code: 127
I'd like to confirm @dmitriyrepin
EDIT: vscode 1.91.1 ia32 @ Windows 10 x64
.vscode/task.json
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "typescript",
"tsconfig": "src\\tsconfig.json",
"problemMatcher": [
"$tsc"
]
}
]
}
.node_modules.bintsc --version
Version 2.6.2
when settings has this:
"terminal.integrated.shell.windows": "C:\Program Files\Git\bin\bash.exe",
the build in typescript tasks don't work (ctrl+shift+b) /build

/usr/bin/bash: c:inetpubwwwrootmyprojectnode_modules.bintsc.cmd: command not found
The terminal process terminated with exit code: 127
@ComradeCow solution worked for me, I polished it up a bit to make vscode happy about deprecations.
{
"label": "tsc watch",
"command": "tsc",
"type": "shell",
"args": ["-w", "-p", "."],
"presentation": {
"echo": true,
"reveal": "never",
"focus": false,
"panel": "shared"
},
"isBackground": true,
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": "$tsc-watch"
}
In addition to the above solution, you could also change the shell for the specific task:
{
"version": "2.0.0",
"tasks": [
{
"type": "typescript",
"tsconfig": "tsconfig.json",
"option": "watch",
"options": {
"shell": {
"executable": "powershell.exe"
}
},
"problemMatcher": [
"$tsc-watch"
],
"group": "build"
}
]
...or make it windows-specific with the "windows" property
@anhallbe - Thanks! Overriding the shell fixed a similar problem I was having with CMDER on Windows.
In addition to the above solution, you could also change the shell for the specific task:
{ "version": "2.0.0", "tasks": [ { "type": "typescript", "tsconfig": "tsconfig.json", "option": "watch", "options": { "shell": { "executable": "powershell.exe" } }, "problemMatcher": [ "$tsc-watch" ], "group": "build" } ]...or make it windows-specific with the "windows" property
What would this look like with the windows specific tag? I think I've tried putting "windows" at just about every level, some levels the editor complains, others it doesn't, but I've not found one that works. I read through the tasks.json schema, but I'm not sure how accurate that is since the typescript type is not listed.
My suggestion for fixing this is to separate the option for specifying the shell used. Instead of just letting user input the path to the executable like now, separate them into two options:
This way, VS Code can judge which shell is used and adjust the path of the tasks.
Duplicate of #35593
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues here. See also our issue reporting guidelines.
Happy Coding!
Most helpful comment
In addition to the above solution, you could also change the shell for the specific task:
...or make it windows-specific with the "windows" property