Is there a setting in VS Code for the Code Runner extension that lets you run in a shell that's different than the workspace's default shell?
For context, my default integrated terminal is powershell. I have the code-runner.runInTerminal setting set (see, e.g., here), and whenever I run python using the extension, it creates a new "Code" powershell integrated terminal (unless one already exists), activates my selected python environment, and runs the code. However, when it tries to activate the environment, I get this popup:
So, I'd like to change the shell that Code Runner uses to cmd, BUT I want to keep using powershell as my default integrated terminal for the workspace.
Changing my workspace's default shell to cmd isn't an option, and neither is changing to a third shell like WSL. This issue indicates to me that the environment activation isn't getting fixed in powershell anytime soon. For now, I've done what the issue suggests and have just stopped Code Runner from activating a new environment in the terminals it creates (set python.terminal.activateEnvironment to false), but I'm worried now I won't be able to have Code Runner use any other python environments than the default one. What can I do?
Related
Ideally, the integrated VS Code terminal, depending on the context, the type of the folder and the extension, executes some commands. For example, when opening a folder containing a Python virtual environment in VS code, the environment is recognized and activated (by the python extension) by default when opening a new integrated terminal instance (situation 1). This is done by running some command similar to source /path/to/venv/bin/activate.
Or, when using the ROS extension to debug nodes, selecting "Start Debugging (F5)" uses the launch.json file to start some nodes and finally starts debugging the desired code. To do so also, there is some command that is executed (also by he ROS extension, I assume) in the integrated terminal (situation 2) to start the debugging process. In case of debugging ROS nodes, the command usually looks something like /usr/bin/env /bin/sh /tmp/someFileName.
But, unfortunately, both of the above mentioned situations fail. I believe this happens because while the extension tries to run these two commands within their respective integrated terminals, the commands do not actually get executed in either situation. Instead, these commands are printed on the top of the terminal, but the state of the terminal is unchanged (as opposed to when the commands would have been executed, in which case depending on the commands some actions are performed). Here are two images to show what I mean. Top, situation 1 and bottom, situation 2.
The fact that these two commands are printed on top of the terminal as soon as the a new terminal instance is opened tells me that the extension tries to execute them, but they do not work for some unknown reasons.
Just to be clear, both of them are run in a seperate VC Code window, they have nothing to do with each other. When I manually run both the commands in their respective terminals I do get the desired results.
Now, I am unsure exactly how to name this issue. But I think this is surely an issue with the integrated terminal, and not a problem of the extensions. I am not sure how one could reproduce this problem.
I did a clean reinstall of VS code by deleting %APPDATA%\Code and %USERPROFILE%\.vscode. Because I am using this on WSL, there is only ~/.vscode-server on the ubuntu side. I manually uninstalled all extensions on WSL but did not delete this folder, in fear of breaking something. The problem still persisted. I have also created an issue on the VS Code GitHub page with nearly the same information.
I am unsure if this is a bug or is there something wrong with my settings. Does anyone know how I could fix this? For smaller use-cases I can still manually enter the command in the terminal. But I am trying to debug a ROS application with nearly 10 different terminals opening up and I cannot be manually entering the command each time to restart the process.
Please let me know if you need any more information. Many thanks in advance.
Edit: both edits to frame the question properly.
Although not related to WSL, I dug a little deeper today as to why in my case the extension commands were not being executed or were being chopped.
I'm an iTerm2 user. iTerm2 has something called Shell Integrations, which allow iTerm to behave differently under certain circumstances, for example, adding markers to each prompt or coloring output with certain text (e.g. WARNING or ERROR)
From time to time, I also use the VSCode Integrated Terminal, which recently added support for reporting whether the previous command errored out with an indicator on the gutter of the Integrated Terminal panel using the exit code.
iTerm can do something similar but the shell integrations mess up completely the VSCode functionality and therefore I changed my .bashrc file to detect if the terminal emulator was iTerm2 or not (which can be done with the it2check utility of iTerm2) so that it only sourced the shell integrations if I was using iTerm2.
The problem is that it2check "eats" some STDIN bytes using dd, specifically, until it finds an n so that it can obtain the name of the emulator. This of course chops the commands on the STDIN until the first n and makes VSCode Extension Terminal commands unusable
The workaround I came up with is to use the value of "$TERM_PROGRAM" as means to distinguish between the different programs. The only caveat is that the value won't be passed if you're inside of a tmux session or similar, but I can live with that.
In your case, I'd check for any process that is either not passing the STDIN to the WSL process or any dot files or shell profile scripts eating up the STDIN they receive.
I suspect that the real problem is that the local process doesn't relay the STDIN contents to the WSL and as a workaround you may try to create a VSCode Integrated Terminal profile that uses SSH to connect to the WSL host so that the STDIN is preserved
I've forked VSCode on Github to try to add a tiny little feature I think would be useful, which adds a new CLI flag to code, to be used inside the VSCode terminal (like code - for stdin). I added the code, wrote tests, and now I want to try out the feature.
I'm developing inside the built-in devcontainer, so I just launched an instance of VSCode from within VSCode, connected to the devcontainer via VNC and tried to use my flag inside the VSCode-OSS terminal. However, I get an error saying "Command is only available in WSL or inside a Visual Studio Code terminal"
According to server.cli.ts, this means that the env variables VSCODE_IPC_HOOK_CLI and VSCODE_CLIENT_COMMAND aren't set, but I don't know who should be setting them, or if I need to launch VSCode in a different way for debugging.
Has anyone using the VSCode DevContainer to write additional CLI flags and knows how to debug them?
The problem: when running a React project (i.e. npm run start) with WSL from the terminal in VS Code, the file "browser.sh" is opened in a new window. The browser is no longer launched.
This is a new behavior with version 1.52. The release notes indicate that they now add the system variable "BROWSER" and use it to launch the browser. In my case it is set to /home/dan/.vscode-server/bin/ea3859d4ba2f3e577a159bc91e3074c5d85c0523/bin/helpers/browser.sh
The browser.sh file is a shell script created by VS Code. It exists and has executable permissions (-rwxr-xr-x).
The workaround: Type unset BROWSER every time a terminal is opened inside VS Code.
The desired solution: Convince VS Code to run the shell script or to launch the default browser directly.
Is there a way to force VS Code to use only python3? It always defaults to python2.7 no matter what I try. I've tried selecting the correct interpreter as python3.7. When I open up terminal, it immediately uses python2.7, In the settings it is pointing at 3.7, but the built in terminal which is nice, always defaults to 2.7.
First, understand that the integrated terminal of VSCode, by default, uses the same environment as the Terminal app on Mac.
The shell used defaults to $SHELL on Linux and macOS, PowerShell on
Windows 10 and cmd.exe on earlier versions of Windows. These can be
overridden manually by setting terminal.integrated.shell.* in user
settings.
The default $SHELL on Mac is /bin/bash which uses python for Python2.7. So VS Code will just use the same python to mean Python2.7. When you open a bash shell, it will load your ~/.bash_profile to apply custom aliases and other configurations you added into it.
One solution to your problem is edit your ~/.bash_profile to alias python to python3. But I do not recommend this because this affects all your bash sessions, even those outside of VS Code. This can lead to nasty side effects when you run scripts that need python to be the system Python2.7.
You can instead configure VSCode to load its own aliases, for its own integrated terminal. First, create a file named vscode.bash_profile in your home directory:
$ cat ~/vscode.bash_profile
alias python=$(which python3)
On my env, python3 is Python3.7. You can set it to the what's applicable on your env (ex. maybe python3.7). Then, in VS Code, look for the Terminal shell args setting:
and then open your settings.json and add these lines:
"terminal.integrated.shellArgs.osx": [
"--init-file",
"~/vscode.bash_profile",
]
Finally, restart VS Code. The next time you open the VS Code terminal, python should now be using your Python 3 installation. This should not affect your bash session outside of VS Code.
Note that, if you have some custom settings from the default ~/.bash_profile, you may want to copy it over to your ~/vscode.bash_profile, so that you can still use it on VS Code (ex. changes to PATH, git-completion scripts..).
Recently when I'm using vscode, everytime I launches the built-in terminal, it automatically uses "source activate base" to launch a anaconda python virtual environment. You can see the screenshot
I don't think I changed anything but it just came up randomly. Can someone help me out?
To prevent automatic activation of a selected environment, add
"python.terminal.activateEnvironment": false
to your settings.json file (it can be placed anywhere as a sibling to the existing settings). However, debugging or running Python code without any activated environment won't work.