When I woke up this morning and launched VSCode my default terminal on launch, and when running tasks is now powershell, instead of Git Bash. I am on windows. I have tried changing the settings.json to no avail. Is there something I'm missing?
{
"workbench.startupEditor": "newUntitledFile",
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
"[javascript]": {
"editor.defaultFormatter": "rvest.vs-code-prettier-eslint"
},
"aws.samcli.location": "C:\\Users\\king\\AppData\\Roaming\\npm\\sam.exe",
"typescript.updateImportsOnFileMove.enabled": "always",
"[html]": {
"editor.defaultFormatter": "vscode.html-language-features"
},
"editor.formatOnSave": true,
"editor.formatOnPaste": true,
"javascript.updateImportsOnFileMove.enabled": "always",
"explorer.confirmDragAndDrop": false,
"diffEditor.maxComputationTime": 0,
"extensions.ignoreRecommendations": true,
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"editor.renderControlCharacters": true,
"[jsonc]": {
"editor.quickSuggestions": {
"strings": true
},
"editor.suggest.insertMode": "replace"
},
"window.zoomLevel": 0,
"editor.accessibilitySupport": "off",
"workbench.editor.untitled.hint": "hidden",
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.external.windowsExec": "C:\\Program Files\\Git\\bin\\bash.exe",
"terminal.explorerKind": "external",
"terminal.integrated.automationShell.linux": ""
}
I found this related SO post making the default powershell, but I didn't see anything that was incorrect about my setting...especially because my goal is the opposite- to stop Powershell!
Update: Version v1.60.0 had a bug. Upgrade to v1.60.1 or higher for a fix.
The bug manifested in the following symptoms:
The Open in Integrated Terminal shortcut-menu command in the Explorer pane's shortcut always uses the built-in default shell (PowerShell on Windows), ignoring the configured one.
The same goes for running tasks (with or without a separate terminal.integrated.automationShell.* setting).
Also, if a given folder or workspace happened to have an integrated terminal open when quitting Visual Studio Code, the shell that is launched when the integrated terminal automatically reopens the next time is again the built-in default shell, not the configured one. By contrast, if reopening doesn't auto-open the integrated terminal, opening it manually does respect the configured default shell, and so does manually creating another shell instance later.
See GitHub issue #132150
The following information turned out to be unrelated to the bug, but is hopefully still useful general information about Visual Studio Code's recent change in how shells for the integrated terminal are configured:
Migrating from the legacy default shell settings to shell profiles:
Recently, the "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings were deprecated and replaced with a more flexible model that allows defining multiple shells to select from, via so-called shell profiles, optionally defined in setting "terminal.integrated.profiles.*", with an associated mandatory "terminal.integrated.defaultProfile.*" setting referencing the name of the profile to use by default - which may be an explicitly defined custom profile or one of the built-in, platform-appropriate default profiles.
Note: * in the setting names above represents the appropriate platform identifier, namely windows, linux, or osx (macOS).
As of v1.60.1, if legacy "terminal.integrated.shell.*" settings are also present, the new settings take precedence (even though the tooltip when editing "terminal.integrated.shell.*" in settings.json suggests that this change is yet to come).
In the absence of both settings, Visual Studio Code's built-in default shell is used, which on Windows is PowerShell,[1] and on Unix-like platforms the user's default shell, as specified in the SHELL environment variable.
Recent Visual Studio Code versions, starting before v1.60 - seemingly as one-time opportunity - displayed a prompt offering to migrate the deprecated settings to the new ones.
Accepting the migration results in the following:
Creation of setting "terminal.integrated.shell.*" containing a custom shell profile derived from the values of legacy settings "terminal.integrated.shell.*" and, if present, "terminal.integrated.shellArgs.*"; that custom profile's name has the suffix (migrated)
Creation of setting terminal.integrated.defaultProfile.* whose value is the migrated profile's name, making it the default shell.
Removal of legacy settings "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*"
If you decline the migration, you can later effectively perform it by re-choosing the default shell, as described below.
Note: The new "terminal.integrated.defaultProfile.*" setting that is created in the process then effectively overrides the legacy "terminal.integrated.shell.*" and "terminal.integrated.shellArgs.*" settings, but the latter won't be removed automatically. To avoid confusion, it's best to remove them from settings.json manually.
Choose the default shell profile to use in order to (re)specify the default shell:
Click on the down-arrow part of the shell-selector icon () on the right side of the integrated terminal, select Select Default Profile, which presents a list of the defined profiles to select the default from - in the absence of explicitly defined profiles, standard profiles are offered (see below).
This translates into a terminal.integrated.defaultProfile.* setting in settings.json, whose value is the name of the chosen shell profile - which may be the name of a built-in profile or one of the ones explicitly defined in "terminal.integrated.profiles.*"
Note: This shell is by default also used for tasks (defined in tasks.json), but that can be overridden with a "terminal.integrated.automationShell.*" setting pointing to the executable of an alternative shell.
Optionally, in your settings.json file, you may create a platform-appropriate terminal.integrated.profiles.* setting with shell profiles of interest:
Note: Even if your settings.json contains no (platform-appropriate) "terminal.integrated.profiles.*" setting, Visual Studio code has built-in standard profiles it knows of and offers them for selection when choosing the default shell.
These standard profiles are a mix of shells that come with the host platform as well as some that Visual Studio detects dynamically on a given system, such as Git Bash on Windows.
To create the standard profiles explicitly, do the following:
Note: You may choose to do this in order to customize the standard profiles. However, if your intent is merely to add custom profiles - see this answer for an example - it isn't necessary to create the standard profiles inside the "terminal.integrated.profiles.*" setting, because Visual Studio Code knows about them even if not explicitly defined.
Via File > Preferences > Settings (Ctrl-,), search for profiles and click on Edit in settings.json below the platform-appropriate Terminal > Integrated > Profiles > * setting; this will open settings.json for editing, with the standard profiles added; simply saving the file is sufficient.
Note: If the "terminal.integrated.profiles.*" setting shown doesn't contain the expected, platform-appropriate standard profiles, a setting by that name may already be present; to force creation of the standard profiles, remove or comment out the existing setting and save the file, then try again.
On Windows, you'll end up with something like the following:
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
"${env:windir}\\Sysnative\\cmd.exe",
"${env:windir}\\System32\\cmd.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
}
}
The answer you link to in your question, which provides an overview of the various types of shells used in Visual Studio Code, has been updated to reflect the information about the new shell profiles.
[1] Note: If a PowerShell (Core) v6+ installation is found, it takes precedence over the built-in Windows PowerShell version.
Edit:1
Note: Now this bug has been fixed by VSCode. Just update your VSCode to the latest version. (17-Sep-2021)
I have a temporary solution.
First paste this code in settings.json and save
"terminal.integrated.defaultProfile.windows": "Git Bash",
"terminal.integrated.profiles.windows": {
"C:\\Program Files\\Git\\bin\\bash.exe": {
"path": "",
"args": []
}
},
Before closing VSCode select Output instead of Terminal
Now you can open VSCode
After VSCode is loaded, you need to click on Terminal. After this you will now see bash.
Select output before whenever you close VSCode.
Reference: VSCode is suddenly defaulting to PowerShell for integrated terminal instead of $Bash in Windows
Note: This is not an solution. I shared this because maybe it can save you from getting disappointed.
This is my first post, if there is any mistake please let me know so that I can correct it.
You can always download and install previous releases from the official website https://code.visualstudio.com/updates/v1_59 (currently at the top).
As version 1.60 was bugged, v1.59 is a good candidate.
Disable automatic updates
Explained here.
Open User Settings File > Preferences > Settings.
Add "update.mode": "none" to your settings.
Install older version
Afterwards you can just overwrite current version with the installation of downloaded version.
Note: Wait for next version to fix it, so remember you had automatic update disabled!
I have same problem but I try run command prompt. I fix it by adding to ...\Code\User\settings.json
"terminal.integrated.automationShell.windows": "cmd.exe",
This could be related to issue 138999 which will add a mitigation/enhancement to VSCode 1.70 (July 2022) with PR 154290 and commit 91b82c0
increase barrier for available profiles to be ready
Wait up to 20 seconds for profiles to be ready so it's assured that we know the actual default terminal before launching the first terminal.
This isn't expected to ever take this long.
For VSCode with synchronized user settings, the profile might take more time than expected to fully load, hence the advantage of that workaround.
Simply replaced the CMD by Git Bash :-) in the settings.json
"terminal.integrated.profiles.windows": {
"PowerShell": {
"source": "PowerShell",
"icon": "terminal-powershell"
},
"Command Prompt": {
"path": [
//"${env:windir}\\Sysnative\\cmd.exe",
//"${env:windir}\\System32\\cmd.exe"
"C:\\PrivateProgramms\\Git\\bin\\bash.exe"
],
"args": [],
"icon": "terminal-cmd"
},
"Git Bash": {
"source": "Git Bash"
//"path": [ "C:\\PrivateProgramms\\Git\\bin\\bash.exe" ],
//"args": [],
//"icon": "terminal-cmd"
}
},
"terminal.integrated.defaultProfile.windows": "Command Prompt"
I have this build system, and I want to modify it so that it will automatically kill the process if it takes more than 10 seconds, how can I do so?
{
"cmd": ["g++.exe","-std=c++17", "${file}", "-o", "${file_base_name}.exe", "&&" , "${file_base_name}.exe"],
"shell":true,
"working_dir":"$file_path",
"selector":"source.cpp"
}
Since a sublime-build is just executing an external process, one way to do this would be to have the build execute an external tool (or script or batch file, etc) that keeps track of time and kills itself.
A second way to do this from within Sublime would be to use a custom build target. This is a command provided via a plugin that you tell Sublime to use in place of the command that it would normally use to execute the build.
An example of a plugin that does something like this is the below. See this video on how to use plugins if you're unfamiliar with using a custom plugin in Sublime:
import sublime
import sublime_plugin
from Default.exec import ExecCommand
class TimeoutExecCommand(ExecCommand):
"""
Drop in replacement for the exec command in Sublime Text build 3210/3211.
"""
def run(self, **kwargs):
self.timeout = kwargs.pop("timeout", 0)
super().run(**kwargs)
if self.timeout:
sublime.set_timeout(self.time_out_build, self.timeout * 1000)
def time_out_build(self):
if self.proc:
self.append_string(self.proc, "[Timeout exceeded: %.1f]" % self.timeout)
self.proc.kill()
self.proc = None
This implements a new timeout_exec command that can be used in builds to have them time out if they don't complete within a specific period of time. As noted in the comment, requires one of the more recent Sublime Text 3 builds (it will not work in the 4xxx builds since those builds have an enhanced exec command).
To use this, you need to add some extra keys to your sublime-build file. An example of a build file that uses this is:
{
"target": "timeout_exec",
"cancel": {"kill": true},
"timeout": 4,
"shell_cmd": "echo \"Start\" && sleep 10 && echo \"Done\""
}
The target key tells Sublime to use this new command instead of the default exec command and the cancel key tells Sublime what extra arguments to provide if you try to cancel the build manually (i.e. from the menu, command palette, etc).
The command also implements a new build parameter of timeout that is the time in seconds after which the build will cancel itself. If the build is still running when the timeout is hit, it will cancel:
Start
[Timeout exceeded: 4.0]
Leaving out the timeout field or setting it's value to 0 disables the timeout, in which case the command behaves exactly as a build normally would.
My current workflow for a project is the following:
build the project (via catkin)
source a setup.sh script (generated by catkin, which I wouldn't like to modify) setting environment variables and the names needed by my executable.
Run "MyProgram", which is only available after sourcing the "setup.sh" script.
I would like to be able to debug my project in Visual Studio Code. To do this, I have defined a task building the executable via catkin, named "catkin build all", and I have defined a second task as:
{
"type": "shell",
"label": "load programs",
"command": "source /some_folder/setup.sh",
"group": "build",
"dependsOn": ["catkin build all"]
}
Which is the "preLaunchTask" of my lanuch.json launch configuration.
Launching debug will correctly compile the project, but execution fails with error "launch: program myProgram does not exist". Indeed program MyProgram can not be found if setup.sh is not sourced, but is should be sourced by the "preLaunchTask".
In my launch.json i can also set "program" to "/full/path/to/myProgram" instead of "myProgram", but in this case shared libraries are not found, as setup.sh would take care of that.
I have also tried to source setup.sh on a shell and then launch visual studio code from the same shell, but this did not solve the "launch: program myProgram does not exist" problem.
Do tasks run on different shells? How can I have the preLaunchTask running in the same shell as the subsequent program code? Or any other hint on how to get my workflow working?
My solution is to use a env_file
In one terminal, source your file such as: source /opt/ros/melodic/setup.bash
Recover the changes by using: printenv | grep melodic
Create a .env file in your repo with the environment variables; (except PWD)
LD_LIBRARY_PATH=/opt/ros/melodic/lib
ROS_ETC_DIR=/opt/ros/melodic/etc/ros
CMAKE_PREFIX_PATH=/opt/ros/melodic
ROS_ROOT=/opt/ros/melodic/share/ros
PYTHONPATH=/opt/ros/melodic/lib/python2.7/dist-packages
ROS_PACKAGE_PATH=/opt/ros/melodic/share
PATH=/opt/ros/melodic/bin:/home/alexis/.nvm/versions/node/v8.16.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
PKG_CONFIG_PATH=/opt/ros/melodic/lib/pkgconfig
ROS_DISTRO=melodic
Add the following line to your launch.json task: "envFile": "${workspaceFolder}/.env"
Note: this could be automated in a prerunTask using:
command: "source /opt/ros/melodic/setup.bash; printenv | grep melodic > ${workspaceFolder}/.env"
Perhaps this might help after a zoom.
Got that info from here
I'm relatively new to sublime 3. I'm trying to use the RegReplace package to create custom regex find and replace commands that I can run from the command palate. I managed to create the custom rules, but don't know how to execute them.
The RegReplace website states: "Once you have replacements defined, there are a number of ways you can run a sequence. One way is to create a command in the command palette by editing/creating a Default.sublime-commands in your User folder and then adding your command(s)"
I edited the file that appeared when I clicked "Preferences: Reg Replace - User" on the command palate, adding the code below:
{
"caption": "Reg Replace: process evernote",
"command": "reg_replace",
"args": {"replacements": ["remove evernote bullets", "last option removal"], "find_only":false}
}
However, this command does not appear on my command palate. How do I execute a predefined find and replace rule in RegReplace?
The file that you get to when you select Preferences > Reg Replace > User is a settings file that stores settings specific to RegReplace.
As the referenced help page mentioned, you need to create a file named Default.sublime-commands inside of your User package (use Preferences > Browse Packages to see where that is if you're not sure) (or open it if it already exists) and then add in your code from above.
A sublime-commands file is a JSON file that expects an array of the commands to be added to the command palette, so you'll need to make sure that you wrap the above in [ and ] to turn it into an array:
[
{
"caption": "Reg Replace: process evernote",
"command": "reg_replace",
"args": {"replacements": ["remove evernote bullets", "last option removal"], "find_only":false}
}
]
I want to have a custom build system but am really not able to make one. I have Gradle 1.2 installed and even the GRADLE_HOME is set correctly now I have the following commend in the build system file
{
"cmd": ["gradle","build.gradle"],
"path": "$project"
}
And the error I get is as follows (when I try to build my project):
[Errno 2] No such file or directory
[cmd: [u'gradle', u'build.gradle']]
[dir: /home/roger/Project/Visage/HelloWorld/src/main/visage/visage/javafx]
[path: $project]
[Finished]
Actually my Project Base directory is HelloWorld and I have my build.gradle there itself. Please help me to write the correct build system or give the correct commands to avoid error and execute successfully. I am currently using UBUNTU 12.04
I think you have to use a shell for your build system. and instead of path I guess you mean "working_dir". can you try this:
{
"cmd": ["gradle"],
"shell": "true",
"working_dir": "${project_path}"
}
cheers,
René
Even shorter Gradle configuration in Sublime Text 3:
{
"shell_cmd": "gradle",
"working_dir": "${project_path}"
}
Go to menu 'Tools > Build System > New Build System...' and paste this text. Then save the configuration file as 'Gradle.sublime-build'.