Our local Macs are set up to run our local server via grep serve
When running from standard terminal, that command builds the project then spins up the local server. To kill it, I can use the break command (command-.).
We're doing a lot more in VS Code now which has the great feature of Terminal built in. However, it appears the command-. doesn't apply to that version of the terminal. So I'm at a bit of a loss...how does one stop the server via the terminal in VS Code?
Crtl+c should kill the currently running process in your terminal (VSCode or otherwise).
Related
I am using VSCODE on mac and trying to run a debugger to stop at breakpoints, when running an NPM script.
The NPM script is a shell script (.sh) and it starts a "watcher" on 4 different repos, that form my local server for the project.
The issue is that when I run the debugger on the relevant NPM script (using vscode's 'debug script' option), it seems like VSCODE has a debugger attached, but it never stops at my breakpoints.
The server itself seems to work fine.
I read a lot of answers regarding debugging NPM scripts, but they always refer to a .js file.
Am I not connecting the debugger in the correct way?
Is it possible to debug a shell script that runs this way?
My guess is that the debugger is only connected to the shell script which works fine, but "doesn't know" about the breakpoints in the actual repos that are launched with the script.
Would appreciate any help.
Thank you.
I am attempting to run an .sh script (which itself is supposed to kick off a series of unit tests in flask) from within Visual Studio Code running in Windows 10 and for some reason no matter what I try it only opens the file for editing instead of actually running the file.
This is the exact command I am typing:
C:\Users\my.user\MyRepo>.\scripts\run-unit-tests.sh
Here are my notes:
This is a brand new installation of Windows 10 where I believe I have enabled WSL2
I am completely unfamiliar with doing development from within Windows (coming from a Ubuntu/Linux background)
My goal is to run this script from within the built in terminal in VS Code, however I have also tried running it from a cmd prompt and also from powershell and both of those also result in opening the file in VS Code.
Addendum: more notes:
I actually have two windows machines. one is my personal machine, the other provided by my work. For whatever reason this file works fine on my personal machine but does not on my work machine. Also the bash script is in a repo which was created by others at my company so i'm certain that this can be made to run without modifying the .sh file itself.
I figured out what was going on.
In windows there are default file associations. Mine was set up to run Visual Studio Code for the .sh file extension. Also, windows does not know how to handle .sh files by default. There were likely many potential fixes for this however the one that worked was for me to re-associate the .sh file extension to open with Git Bash which I happened to also have installed on this machine.
Thanks all who tried to help.
I am curently developing a Rust program on Windows 10. A few months ago I created a library package using cargo. Since then, I've been developing this program. Whenever I want to execute what I have, I goto to cmd and execute the following command inside my cargo folder:
cargo run --release --bin main
But, a few weeks ago something strange started to happen. Whenever I execute this same command, I notice that the program in fact starts but it finishes preemptively (I know this because of the output to the terminal). When the program finishes it is supposed to write to the terminal "FINISHED". But this never happens. If I execute the command again (without changing the code), this time the only thing that's printed to the terminal is the build message that cargo puts out. Then, when I execute a third time, I have the following message on my terminal:
error: 'cargo.exe' is not installed for the toolchain 'stable-x86_64-pc-windows-msvc'
To install, run `rustup component add cargo --toolchain stable-x86_64-pc-windows-msvc`
Then if I execute the suggested command, I have the following:
component 'cargo' for target 'x86_64-pc-windows-msvc' was automatically added because it is required for toolchain 'stable-x86_64-pc-windows-msvc'
What's weird is that if I execute the previous cargo run command on the Ubuntu terminal application that I have (it simulates a linux terminal, but I am still on my windows file system), this problem doesn't occur. I can execute 100 or 1000 times and no problems. But this isn't good, since my program creates a multi threaded environment and my Ubuntu terminal is like a virtual machine, so I don't believe that I have access to all of my laptop's memory.
Currently I have the following version of rust on windows and my ubuntu terminal:
rustup 1.18.3 (435397f48 2019-05-22)
What I have been doing until now to solve this is on my windows is to reboot my computer and reinstall rust, since when I execute "rustup self uninstall" sometimes an error of not having permissions to install it appears (I only have 1 user on my pc and supposedly I have admin privileges).
I have googled this situation, but I haven't found anything regarding rustc disappearing when executing cargo run. Now I can't even run my program on windows cmd, since this problems happens every time.
The problem was the anti virus I had on my PC.
After replacing it the program is working perfectly and finishing without the problem I had with rustc.
I would like to build/launch the VSCode source code in the native Bash for Windows client. I have followed the steps outlined in the VSCode wiki on how to contribute, and everything is working as expected (All commands have been run on the WSL terminal following the Linux instructions)
After running yarn run watch, I try to launch VSCode by running DISPLAY=:0 ./scripts/code.sh from the source code directory, but nothing happens. I get two duplicate warnings:
[21496:1128/120229.392130:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected
but I'm not sure if this is causing the problem. I have an X Server client running, and have used to to successfully launch native Windows applications through WSL (terminator, emacs, etc.)
Is what I'm trying to do possible? If so, how can I make it work?
Amazing that you asked this! I was attempting to do the exact same thing at (it seems) the exact same time. Here's my process.
Install XMing
Install the xfree apps
Set DISPLAY=:0
Run xeyes ==> Awesome googly eyes!
Attempt to build vscode from source. The build docs seem to be incomplete b/c I had to install a ton of libraries beyond those listed e.g.
yarn
gulp
gulp-cli
pkg-config
libx11-dev
libxkbfile-dev
libsecret-1-dev
libgtk2.0-dev
libxss-dev
gnome-dev
libgconf2-dev
libnss3-dev
libasound2-dev
Eventually get the yarn tasks to finish such that I could run code.sh
./scripts/code.sh
[20474:1128/153959.035267:ERROR:bus.cc(427)] Failed to connect to the bus: F
ailed to connect to socket /var/run/dbus/system_bus_socket: No such file or
directory
[20474:1128/153959.081986:WARNING:audio_manager.cc(295)] Multiple instances
of AudioManager detected
[20474:1128/153959.082101:WARNING:audio_manager.cc(254)] Multiple instances
of AudioManager detected
Looking at ps I see that the process was running.
Conjectures
It seems that building from source from WSL is not yet supported. Or maybe you can build the artifact, but you can't connect to the Windows display to show it. Based on the quality of the xeyes session, it looks like a very, very, very primitive experience e.g. still using WinXP-style minimize / maximize / close icons.
I was literally writing an Issue on their github page when I thought I'd do one last search and found this post. Much of vscode treats WSL as a second-class environment on Windows. Recent work seems to suggest that things are going to get better as driving to integration between Windows' two internal environments continues to improve (e.g. https://github.com/Microsoft/vscode/issues/39144)
Update 2017-11-30
Based on some pursuit via Github, it seems that this issue has been reported to the WSL team: https://github.com/Microsoft/WSL/issues/2293. It appears to be under active consideration by the WSL team. I've added some commentary about my use case there.
Using Xcode 3.1 on OSX 10.5; is it possible to attach (the debugger) to a running remote process?
I know that it's possible to start and debug a remote process (as explained here), but it would be great if I could find a way to attach to an already running remote process...
edit to add: Thanks. I've submitted a bug report to Apple. Will update this question if/when I hear back from them.
There is no nice gui for it in XCode but you can do it this way:
start a second instance of the program from XCode with remote debugging,
use the GDB attach command from the console
Step by step instructions:
Follow Apple's instructions to set up remote debuging:
Find out the process-id of the running instance of your program on the remote box:
ssh "remotemachine" 'ps -x -w -w' | grep "AppName"
(you can also use ARD and ActivityMonitor)
Put a breakpoint to your app main, and start a second instance from the Debugger (on the remote box)
In the GDB console (Run/Console menu) enter:
attach process-id
Now you have you XCode attached to the running process. You can now use the graphical debugger.
(In early XCode, there was no GUI for attaching to local processes, so this trick/hack was the solution...)