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"
Related
I'm trying to edit my launch settings for a CMake project in Visual Studio, but the option is greyed out. I can manually open launch.vs.json file, but the settings there won't behave.
Probably the greying out and the fact that the settings won't behave are linked.
I am running the x64-Debug configuration.
This is how launch.vs.json looks like for me:
{
"version": "0.2.1",
"defaults": {},
"configurations": [
{
"type": "default",
"project": "CMakeLists.txt",
"name": "CMakeLists.txt",
"args": [
"first-argument"
],
"currentDir": "C:\\repos\\myproject"
}
]
}
Since the type of the configuration is "default", I would assume it applies for any configuration that isn't configured. But it doesn't because my "first-argument" is not read.
int main(int argc, char* argv[])
{
if (argc>1)
{
cout << argv[1];
exit(EXIT_SUCCESS);
}
else
{
exit(EXIT_FAILURE);
}
}
The above yields failure.
How to properly configure the debug parameters and how to ungrey Debug and Launch settings?
The Configure CMake debugging sessions documentation says that
If you don't have a debug target selected, this option is grayed out.
Running the x64-debug configuration sounds like the option shouldn't be greyed out, but it still is because you're debugging the Current Document as a target, which Visual Studio doesn't consider a real target. This means that Current Document is neither a Debug, nor a Release target, so the option is greyed out, even if you run it with the configuration named x64-Debug.
Real targets have a drop down menu on the right, usually with a single item mentioning the type of the selected target.
This means you need to select a real target, which should be something like myproject.exe for you.
According to the launch.vs.json schema reference (C++) documentation page, "type": "default" refers to whether the project is a library or an executable, and default just means that it's an executable. It has nothing to it being the default configuration.
The relevant setting to link debug configurations to targets is projectTarget, which is not set in your case. It could be that it used to be that the default would make this configuration available for all targets, including the virtual Current Document, but this would have been an undocumented feature that was unexpectedly deprecated without notice in a new Visual Studio release. This could explain, why it used to work, but it doesn't anymore.
According to the launch.vs.json schema:
projectTarget must exist already and match the name in the Debug Target dropdown.
The easiest way to create a real launch and debug configuration is to
delete your launch configuration,
select a real target, such as "myproject.exe", and make sure it says Debug on the drop-down menu on the right.
Go to Debug -> Debug and Launch settings for myproject.exe, which should open launch.vs.json with a valid configuration, now fill in the "args" parameter as you wish.
Your final configuration should probably look like similar to this:
{
"version": "0.2.1",
"defaults": {},
"configurations": [
{
"type": "default",
"project": "CMakeLists.txt",
"projectTarget": "myproject.exe (myproject\\myproject.exe)",
"name": "myproject.exe (myproject\\myproject.exe)",
"args": [
"first-argument"
],
"currentDir": "C:\\repos\\myproject"
}
]
}
I hope this will serve me as a good reminder to spend more time on documentations and less time messing around.
The answer for me was that somehow the "Startup Item" magically got deselected, so there was no context for Debug and Launch Settings.
In Solution Explorer, right-click on the executable that is the target of the Debug Launch -- "myproject (executable)" in this case -- and select Set as Startup Item.
Now, whenever this executable is selected in the Solution Explorer, the option "Debug and Launch Settings for myproject" appear in the Debug dropdown menu.
I know that when creating a .desktop file, one can set the metadata::trusted as true and false, in order to be able to launch the icon as an executable.
What is intriguing me however is the fact that:
When right-clicking on the .desktop file and "Allow launching" apparently the only thing it does is to set the metadata::trusted to true. The icon, however, changes, as expected, instantly to the icon described in the .desktop file Icon=.
However when setting the metadata::trusted to either false or true via command-line the icon doesn't seem to change its behavior
$ gio set android-studio.desktop metadata::trusted false
Once I refresh the Desktop manually (Alt + F2 >> restart) the environment refreshes and the icon turns to be executable again, BUT the whole environment is restarted.
So, What does exactly "Allow/Disallow launching" does after setting the metadata::trusted? How does it refresh the metadata in the .desktop itself without refreshing the whole Desktop?
Your question is exactly the same as what I'm looking for.
On Ubuntu 18.04 (GNOME 3.28):
dbus-launch gio set file.desktop "metadata::trusted" yes
and (although this is not quite what you need)
killall nautilus-desktop && nautilus-desktop & disown
Ubuntu 20.04 (GNOME 3.36):
dbus-launch gio set file.desktop "metadata::trusted" true
but no nautilus-desktop...
dbus-send --type=method_call --print-reply --dest=org.gnome.Shell /org/gnome/Shell org.gnome.Shell.Eval string:'global.reexec_self()'
or something like systemd*...
Look at this code:
https://gitlab.gnome.org/GNOME/nautilus/commit/1630f5348
and here search "trusted":
https://download.gnome.org/core/3.36/3.36.2/sources/
nautilus-3.36.2/src/nautilus-file-operations.c
nautilus-3.36.2/src/nautilus-mime-actions.c
It may turns out to be simpler.
From desktop-file-utils.
man desktop-file-install
For example:
desktop-file-install --mode=0755 --dir=$HOME/Desktop /path/to/source/file.desktop
Quiet interesting, I've used combination of the two previous answers in order to "Allow Launching" .desktop file located at my desktop within Kali Linux 2022 with GNOME Shell:
desktop-file-install --mode=0755 --dir=$HOME/Desktop ~/Desktop/Telegram.desktop
dbus-launch gio set ~/Desktop/Telegram.desktop "metadata::trusted" true
Note the order of the execution of the commands is important!
Here is similar topic at Ask Ubuntu: .desktop files - Allow launching - set this via CLI.
Also for these who are interested in here is How to install the latest version Telegram for Desktop via CLI which was the reason to searching for the current topic.
I have a minimal Rust/OpenGL app on Windows. I'm using Visual Studio Code, LLDB, and Glutin (a library resembling GLFW).
Launching via cargo run opens an empty window, but when launching via LLDB, no window opens. I've confirmed both in LLDB and with println! that the context-creation functions are being called and the main loop is executing. In other words, I've verified that all lines of code are reached. The same holds true whether running from within VSCode or not.
I'm using a 32-bit Rust toolchain, stable-i686-pc-windows-gnu, because LLDB doesn't fully support 64-bit Windows. Aside from this issue, LLDB seems to be working as expected.
Below is main.rs, which is adapted from the Glutin readme. (Glutin is a Rust library similar to GLFW.) I've deleted all but the essentials necessary to open a window.
Desired behavior: The window opens when the program launches from LLDB, the same as it does when the program launches from outside LLDB.
Actual behavior: The window doesn't open when the program launches from LLDB.
Question: What could explain this difference in behavior? I.e. why would the window not open from LLDB when it does from the terminal?
extern crate gl;
extern crate glutin;
fn main() {
let events_loop = glutin::EventsLoop::new();
let window = glutin::WindowBuilder::new();
let context = glutin::ContextBuilder::new();
// When running outside LLDB, this line causes the window to appear.
// The let binding is necessary because without it, the value will be dropped
// and the window will close before the loop starts.
let gl_window = glutin::GlWindow::new(window, context, &events_loop).unwrap();
// Normally, we'd make the window current here. But it's not necessary
// to reproduce the problem.
loop {
// This is where we'd swap the buffers and clear. But it's not necessary
// to reproduce the problem.
}
}
Partial answer: As a workaround, you can attach LLDB to a running process instead of launching the process from LLDB. In VSCode, you can do this with: Add Configuration -> LLDB: Attach by Name. With this workflow, the OpenGL window opens just like it would if LLDB weren't involved. Unfortunately, attaching is significantly less ergonomic.
Update: I prefer to launch with the debugger rather than attach. I've found that Rust's MSVC x64 toolchain along with Microsoft's C/C++ debugger works well for this use case. The steps that work for me are:
If necessary, install MSVC toolchain: rustup install stable-x86_64-pc-windows-msvc
Set the MSVC toolchain as default: rustup default stable-x86_64-pc-windows-msvc
Update Rust: rustup update
Install Microsoft's C/C++ extension for Visual Studio Code. The extension includes a debugger that's compatible with the MSVC binaries that Rust compiles.
Add a debug configuration to Visual Studio Code. I started by adding the default configuration but had to modify it. Ultimately, this is what I had in .vs-code/launch.json--note that the string rust-test is unique to the project:
-
{
"name": "(Windows) Launch",
"type": "cppvsdbg",
"request": "launch",
"program": "${workspaceFolder}/target/debug/rust-test.exe",
"args": [],
"symbolSearchPath": "${workspaceFolder}/target/debug/rust-test.pdb",
"stopAtEntry": false,
"cwd": "${workspaceFolder}/target/debug",
"environment": [],
"externalConsole": true
}
I'd still be grateful if anyone has any thoughts about the LLDB issue. Although the MSVC toolchain solves my problem for now, there may be others out there who really want to use LLDB and come across this question.
I'm currently developing an application with QT 4.8 with a "Launch on login" option. My main problem currently is that I can't seem to find a proper way to make the program launch itself after login on Linux (Fedora 20 in my case).
My program should be able to run in the background without stopping fedora to launch.
I would also like to avoid having to ask for any sort of admin privilege since my application doesn't require any (except maybe for this option).
Finally found out about "home/.config/autostart/.desktop".
I'll have to create autostart if it's not created but from there I can chose to make or delete the file depending on what my user decided to do.
The .desktop file have to follow a particular syntax (which is not a problem for me)
[Desktop Entry]
Type=Application
Exec=</path/to/binary or command to execute>
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=<Name_to_be_displayed>
Comment=<optional comment>
In my case, I can just remove the "comment" line since just the name of the application should be enough for the user to recognize it.
You can Either keep your executable in side /etc/rc.d/rs or inside /etc/init.d folder, so that it can automatically start once device is up.
Hope this Helps.
Each user has a .bashrc file located in their home directory, you could append a command to run your application to the end of that.
That will run when only that user logs in (I think either with graphical or terminal session)
To run for all users, look at creating a systemd service if you dare, or append a line to the end of /etc/rc.local. You'll need to be root for that though.
EDIT: Don't forget to put an ampersand at the end of the command to run in background.
I'm running on MacOS X and I'm using Sublime Text 2 to code.
I've found the command + B option to build and command + shift + B to build and run.
Is it possible to run a program (or script) and pass arguments. Exemple:
myProg arg1 arg2
Note: I'm using multiple languages (C++, Java, Python), so I hope there is a way to set the arguments for each project and not for all build.
Edit
I want to set the parameters for a program call, a little bit like in eclipse where you can set the arguments when you run your program.
For each project you can create a .sublime-project file with your specific build_system on it:
{
"folders":
[{
"path": "src"
}],
"build_systems":
[{
"name": "Run with args",
"cmd": ["python", "$file", "some", "args"]
}]
}
This way you don't pollute the global Build System menu and won't have to worry about switching build system as you switch projects. This file is also easy to access when you need to change the arguments:
Cmd-Shift-P > Edit Project
InputArgs does precisely what you're looking for. It shows an input dialog every time you run build(ctrl+b) and you can supply it with space separated arguments from within sublime text.
I found a simple solution is create a python file in the same directory:
import os
os.system("python filename.py some args")