-
Notifications
You must be signed in to change notification settings - Fork 29k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VS Code holds onto parent console when launched via command line #66750
Comments
FWIW, The console is working as-designed. Since there is a connected client application, we won't exit because we don't want to sever its standard input/output/error handles (or the console handle it has allocated.) |
@Tyriar We have had some issues like this in the past. I do not know nearly enough about Electron, Windows or Windows console infrastructure to make an informed decision. If you have some ideas, solution, let me know. |
@DHowett-MSFT we don't call AttachConsole anywhere AFAIK, is there any other way to attach to the console? Doing a search of the whole codebase+deps the only place AllocConsole, FreeConsole and AttachConsole are used is within node-pty/winpty. |
We're definitely seeing Code (
Unfortunately, I don't have symbols for Code/electron, so I can't point out the originating line. (This backtrace was generated by setting a breakpoint on conhost's connection request handler and then investigating the originating process to see where it was stuck.) |
I am, however, convinced that this line is the cause. I can't find |
@DHowett-MSFT I just spotted that as well, maybe the Electron build we're on isn't official. @bpasero our Electron builds may be being built without OFFICIAL_BUILD set: This likely has performance implications as well if this is the case. |
@Tyriar I got some homework for you:
|
@Tyriar it looks like only starting with Electron 4.0.x we will benefit from this flag being set. //cc @deepak1556 |
Electron does build with chromium |
OK I'm a little confused now, doesn't code.cmd do the following:
Even adding this line to code.cmd |
@deepak1556 does main.cc not get run in Electron as it's replaced by atom_main.cc? |
@Tyriar in your test case can you make sure the env variable |
@deepak1556 I checked the renderer's process.env and it was there, so it seems to have been set all the way through. It's also set explicitly here in the CLI before launching the main process: There's also some code here that deals ELECTRON_NO_ATTACH_CONSOLE inside the main process when it's setting up its env: But it looks like it just carries it over: |
Adding @joaomoreno who seems to have added I am still not fully understanding the issue here and if the |
I now have this same problem. I execute "code ." and Visual Studio Code opens and immediately closes. |
On Windows 10:
Or similarly:
The same thing in PowerShell, terminal won't quit after typing This is minor but quite annoying. |
If I put in my environment variables the following path "C:Program FilesMicrosoft VS Code" and change the name of the .exe file from "code.exe" to "vscode.exe" would it have consequences for the correct functioning of VS Code? At first glance it seems a possible solution that prevents a cmd window from opening when I run vscode that was previously run code |
It will be even worse. In addition to holding the console, it will spam debug messages to it. |
Two years with the same problem, no solution for an annoying cmd console popup? I also don't understand what the problem is with changing the environment variable and pointing to "C:/Program Files/Microsoft VS Code" instead of "C:/Program Files/Microsoft VS Code/bin". When one points the variable to "C:Program Files/Microsoft VS Code" the pop up disappears. So I was reading the only solution is not to start VS Code from the command "Run" and open it from the graphical interface? |
I solved my problem following @kevincharp solution described here. In my case, I had to change from |
Now, exit the shell in which you started the "code.cmd" script, while VS Code is still running. Console will stay open, unless
|
Another solution I found was to install VS Code with Systems Installer, and verify that the environment variable is |
Again, this is irrelevant to the type of installer. (I'm using system.) |
I don't understand what the problem would be with directly executing code.exe and not executing code.cmd? code.exe does not start a debug? |
When you run |
The |
In short, I understand that vscode is executed in different ways... if it is executed from the console, code.cmd is executed and code.exe is executed from the graphical interface. It does not seem like a correct way to execute a program that is normally used. run from the graphical interface, and it turns out that if you start from it, a debug process does not run. On the other hand, the terminal window that opens automatically and remains open while code is executed is annoying and requires having a more open window. Something that could be avoided. |
I totally forgot about this brilliant gem of insanity… I'm so used to NOT force closing the terminal, I didn't even try to test application behavior under such condition. |
In either Windows terminal or cmd.exe, I can type For a thirdparty program like So what's the difference for VSCode to not capable of doing this? |
There's "a lil' bit o' difference" between starting a program from command prompt or running it by other means. |
Workaround for powershell is to launch vscode in a runspace instead. This seems to work without consequences.
|
@Exathi's fix isn't working (at least for me) anymore. My current workaround is as follows: function Start-VSCode {
Start-Job -ScriptBlock {
Start-Process -FilePath $(where.exe code-insiders.cmd | Select-Object -First 1) -NoNewWindow -ArgumentList $args
} -ArgumentList $args | Out-Null
}
Set-Alias -Name code-insiders -Value Start-VSCode Swap |
That's still only workarounds. |
Repro:
code
exit
Repro's in stable and insiderrs and does not repro in Atom which is also on Electron 2.
Advice from Windows console team:
Starting with @joaomoreno who might know who to send this to, not sure who the real owner is though.
The text was updated successfully, but these errors were encountered: