I'd find it convenient to be able to quickly recall past commands issued in the terminal. In Matlab one can simply select any number of those from the Command HIstory panel, and reissue them in the Terminal all at once:
In VS Code (on Windows), I know there is a command to pull up the log text file:
(Get-PSReadlineOption).HistorySavePath
But I find this extremely cumbersome as a solution to call up multiple lines at a time. Is there an VS Code addon that creates a Matlab-like Command History panel with timestamped commands (didn't find any searching myself)? Or is such feedback taken into consideration by Microsoft?
See v1.70 release notes:
Triggering the Terminal: Run Recent Command... will bring up a QuickPick panel of recent terminal commands in which you can search, fuzzy or not, through the recent commands.
There are some examples of commands for going to the next item in the list, for example.
See the supported shells and OS's mentioned below. I believe it is still accurate. Git Bash on Windows doesn't work with this new recent command functionality, but powershell does. Support for MacOS and linux is stronger: bash, powershell and zsh.
And see v1.69 release notes: run recent command:
Some other functionality of the command:
In the current session section, there is a clipboard icon in the right
of the Quick Pick that will open the command output in an editor. Alt
can be held to write the text to the terminal without running it. The
amount of history stored in the previous session section is determined
by the terminal.integrated.shellIntegration.history setting.
There is currently no keybinding assigned by default but it can be
hooked up to Ctrl+Space for example with the
following keybinding:
{
"key": "ctrl+space", // whatever keybinding you want
"command": "workbench.action.terminal.runRecentCommand",
"when": "terminalFocus"
}
This might help (coming to v1.64):
Terminal shell integration
The terminal now features experimental opt-in shell integration which
allows VS Code to gain insights on what is going on within the
terminal as it was previously a black box. When enabled using
"terminal.integrated.enableShellIntegration": true, arguments to run
a shell integration script will be injected into your terminal profile
if possible. The script itself mostly just injects invisible sequences
into your prompt, providing us with information like where the prompt,
command and command output is, what the current working directory
(cwd) is for each command and the exit code of each command.
Shell integration enables the following new features:
Run recent command: Since we know what commands are run, we have
exposed a command that allows you to view and run them again in a
quick pick.
Developer: Run Recent Command run this command from the Command Palette
The current shells supported are pwsh for Windows and pwsh, bash and
zsh for Linux and macOS.
from release notes: terminal shell integration
Although I switched to powerShell on W11 to test this feature - which should be supported - I can't get it to work just now. I wanted to see if you could pick multiple command entries in the QuickPick to run a series of them, but I doubt you can. But at least you get a nice list of recent commands.
Related
When I open the terminal in VS Code, the terminal opens for about half a second, crashes, and outputs this message:
The terminal process "/bin/zsh '-l, '" terminated with exit code: 1.
What could possibly be the cause of this problem. and how do I fix it? I'm using a Mac.
You would want to check your user settings first. Review terminal.integrated settings that could affect the launch.
You're using a Mac, so on macOS, go to Code > Preferences > Settings. In the settings, you may want to search for this:
Just in case you modified settings.json without knowing, you could by typing in #modified or accessing it by Filter Settings (top right) > Modified.
If you did not modified anything, then it may be due to these:
Test your shell directly. Try running your designated integrated terminal shell outside VS Code from an external terminal or command prompt. Some terminal launch failures may be due to your shell installation and are not specific to VS Code. The exit codes displayed come from the shell and you may be able to diagnose shell issues by searching on the internet for the specific shell and exit code.
Use the most recent version of VS Code. Each VS Code monthly release has many updates and fixes and may include integrated terminal improvements. You can check your VS Code version via Help > About (on macOS Code > About Visual Studio Code). To find the latest version of VS Code, go to the VS Code release notes. You may also want to check that you have installed the latest version of your shell.
Use the most recent version of your shell. If your shell is installed separate from your platform, try installing the latest available version of the shell. The same advice applies if you are on an older build of your operating system. For example, some older versions of Windows 10 did not work well with the VS Code terminal.
Enable trace logging. You can enable trace logging and capture a log when launching the terminal. Logging often reveals what is wrong as all arguments used to create the terminal process/pty are recorded. Bad shell names, arguments, or environment variables can cause the terminal to not launch. Keep this log for later if your problem isn't solved.
Exit codes and shells
Search for the specific shells or exit codes in Google (if provided), maybe it would help.
If these still did not help, you may consider searching it in Google (mainly Stackoverflow or github).
Reference link: https://code.visualstudio.com/docs/supporting/troubleshoot-terminal-launch
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
The integrated terminal in VS code means that you can run builds, scripts and other commands and see the results as is. Sometimes though they produce output files that you'd like to view in an editor, like a logfile or exception trace.
Is there a way of running a built-in command in the terminal to say 'please open this file in vscode', specifically in a codespace? On macOS, you might use 'open' or 'start' on Windows, but this only works if your codespace is hosted on the same machine that you're browsing to.
It would be great if there was a command that could be run that would open up the corresponding file in vscode, such that you could set the VIEW or EDITOR environment variables and have such operations edit in the file itself. Then (for example) running git in the integrated terminal would open a new vscode editor for writing the git message, instead of the default vi/emacs/notepad/edit.com/pico/nano.
Yes you can. Use the command:
code filename
Or, if you are running an early release (or GitHub codespaces):
code-insiders filename
It's possible with VS code via installing a shell command, as seen in this SO question: How to open Visual Studio Code from the command line on OSX?
Is the same thing possible with Jetbrain's Rider?
It is possible to open any file, folder, or solution and project in Rider for editing.
Here is a corresponding help page.
If you use a standalone Rider, you need to create a shell script. Call the action "Tools | Create Command-Line Launcher...". Then you will be able to call rider in a terminal as the shell script is by default created in /usr/local/bin.
In the case of using Toolbox installations, all scripts should be generated using Toolbox. Take a look at Create Command-line Launcher Intellij not found to find out how to set it in Toolbox.
Rider, in my case at least, and I installed it on Linux via snap, comes with a built-in rider command. It does open Rider, however, the issue is that the terminal becomes an output for logs from Rider. Additionally, as soon as I close the terminal, Rider gets closed as well. I guess the Rider process becomes a child process of the shell instance that I used to invoke it.
I'm trying to follow along with a tutorial here, and it asks me to use the Command Palette to do things like dotnet run and dotnet restore, by typing dotnet: Restore Packages into the Command Palette.
I have tried installing the C# extension, and restarting the program several times. Everything else seems to be working normally, but not the Command Palette.
I've found a work around, which is to just use the terminal, but I'd like to gain a better understanding of why I can't seem to get the same functionality as described in the tutorial.