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.
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
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?
I wonder how to use the code command to open the VS Code with the integrated terminal launching within with some commands running that I pass directly to the integrated terminal.
Right now I need to do a couple of actions to get it done:
open VS Code via code .
manually open the built-in terminal and run a command like npm run start
Maybe it's possible to open VS Code like this: code . --exec 'npm run start', and it may open the editor and also run another command in the integrated terminal just after VS Code is ready for work.
I look through the documentation and I couldn't find anything useful for this case. Maybe I need to look for something like plugin or tricky bash/zsh script?
Reminder: it’s important to run these “passed” commands via CLI directly in the integrated (built-in) terminal of the newly opened VS Code instance. I know that it's possible to open the editor and then run commands, like code . && npm run start, but it will be just another command in sequence after code, it's not the same as running commands in integrated terminal.
Thanks.
I'm using Eclipse to develop application for embedded systems.
One of the options of Eclipse configurations are "Program to run after programming/building"
Usually, on that textbox it's the path to our .exe generated before, but on this case I want to run a serial port terminal, like this:
terminal -COM=9 -baud=9600...
My goal here it's to have that terminal printing on Eclipse console. Is that possible?
You could use the Target Management platform to achieve this result. Sadly, I did not try this, so cannot tell whether it works or not, but should be according to the about page.