The terminal shell path "..\..\..\vsCode\git\bin\bash.exe" does not exist in VS Code Windows

Question

I am trying to set a portable development Environment:

VS Code - Portable mode git-bash - portable Node.js - portable

VS Code throws Error: The terminal shell path "......\vsCode\git\bin\bash.exe" does not exist

I have C:......\Documents\Storage\vsCode\data\user-data\User\settings.json and C:......\Documents\Storage\vsCode\git\bin\bash.exe

settings.json:

{
    // Git Bash
    "terminal.integrated.shell.windows": "..\\..\\..\\vsCode\\git\\bin   \\bash.exe"
}

It works in CMD:

C:\.........>cd C:\...........\Documents\Storage\vsCode\data\user-data\User

C:\.......\Documents\Storage\vsCode\data\user-data\User>cd ..\..\..\git\bin\

C:\.......\Documents\Storage\vsCode\git\bin>

Can you guide me how to deal with relative path in VS Code without setting global variables in the operating system. I will need to do the same thing with Node.

Sorry for the messy post but I am fairly new to posting here.

Grayling

Answer 1

You can follow below link : https://code.visualstudio.com/docs/editor/integrated-terminal

You need to edit the terminal integrated path in settings.json file to which ever thing you want it to compile it with

See the URL in the screenshot to find the location for settings.json file at my end:

Gelatinate

Answer 2

I searched for "shell path" in the VS Code settings and noticed that the path was wrong (Program Files instead of Program Files (x86))

I had to change it to

 "terminal.integrated.shell.windows": "C:\\Program Files (x86)\\Git\\bin\\bash.exe",

Workmanship

Answer 3

@Rhatalin thank you for the suggestion. I had the same issue on Windows 10. After updating below setting in settings.json (File -> Preferences -> Settings search for shell and choose Terminal-Integrated-Automation Shell: Windows -> Edit in settings.json) the issue was gone.

"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe"

Shul

I was looking for a relative path not absolute. for example if i have the VS code installed on a thumb drive which is E:\\portables\\VS code and Portable bash at E:\\portables\\Git, next time I move to another PC and have my drive letter changed I need to change the path. But if it is relative I only care about the portables directory in the tree not above. – Grayling

Answer 4

After a Windows update, I got the same error. I had to add escape \ characters to each backslash in the path to get it to work again. (check your path to make sure each single \ is double \) This works: "C:\Program Files\Git\bin\bash.exe" This does not work: "C:\Program Files\Git\bin\bash.exe"

Phrenic

I think SO removed your double slashes – Oncoming

Answer 5

Since you can use environment variables in a settings.json, as illustrated here, you can use the new (Q3 2023) GIT_SHELL_PATH variable:

"terminal.integrated.shell.windows": "${env:GIT_SHELL_PATH}"

With Git 2.42 (Q3 2023), add more "git var"^(man) for toolsmiths to learn various locations Git is configured with either via the configuration or hard-coded defaults.

See commit ed773a1, commit 576a37f, commit 15780bb, commit cdd489e, commit f74c90d, commit 1e65721, commit d6546af (27 Jun 2023) by brian m. carlson (bk2204).
See commit 4db16f5 (27 Jun 2023) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 89d62d5, 04 Jul 2023)}

var: add support for listing the shell

^{Signed-off-by: brian m. carlson}

On most Unix systems, finding a suitable shell is easy: one simply uses "sh" with an appropriate PATH value.
However, in many Windows environments, the shell is shipped alongside Git, and it may or may not be in PATH, even if Git is.

In such an environment, it can be very helpful to query Git for the shell it's using, since other tools may want to use the same shell as well.
To help them out, let's add a variable, GIT_SHELL_PATH, that points to the location of the shell.

On Unix, we know our shell must be executable to be functional, so assume that the distributor has correctly configured their environment, and use that as a basic test.
On Git for Windows, we know that our shell will be one of a few fixed values, all of which end in "sh" (such as "bash").
This seems like it might be a nice test on Unix as well, since it is customary for all shells to end in "sh", but there probably exist such systems that don't have such a configuration, so be careful here not to break them.

git var now includes in its man page:

GIT_SHELL_PATH

The path of the binary providing the POSIX shell for commands which use the shell.

---

"git var GIT_SHELL_PATH"^(man) should report the path to the shell used to spawn external commands, but it didn't do so on Windows, which has been corrected with Git 2.46 (Q3 2024), rc0 batch 3.

See commit 9ed143e, commit 877da5e, commit 92fe7c7, commit f1ed769, commit 193eda7, commit ce68178, commit 0593c1e (13 Jul 2024) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 76e018b, 17 Jul 2024)}

var(win32): do report the GIT_SHELL_PATH that is actually used

^{Reported-by: Phillip Wood
Signed-off-by: Johannes Schindelin}

On Windows, Unix-like paths like /bin/sh make very little sense.
In the best case, they simply don't work, in the worst case they are misinterpreted as absolute paths that are relative to the drive associated with the current directory.

To that end, Git does not actually use the path /bin/sh that is recorded e.g. when run_command() is called with a Unix shell command-line.
Instead, as of 7762975 ("Do not use SHELL_PATH from build system in prepare_shell_cmd on Windows", 2012-04-17, Git v1.7.11-rc0 -- merge listed in batch #3), it re-interprets /bin/sh as "look up sh on the PATH and use the result instead".

This is the logic users expect to be followed when running git var^(man) `GIT_SHELL_PATH``.

However, when 1e65721 ("var: add support for listing the shell", 2023-06-27, Git v2.42.0-rc0 -- merge listed in batch #7) introduced support for git var GIT_SHELL_PATH``, Windows was not special-cased as above, which is why it outputs /bin/sh` even though that disagrees with what Git actually uses.

Let's fix this by using the exact same logic as prepare_shell_cmd(), adjusting the Windows-specific git var `GIT_SHELL_PATH`` test case to verify that it actually finds a working executable.

Stepheniestephens