Vscode: terminal stays open after process exit

[payonel]

Initially I thought this was an issue with MIEngine, but they report that it is up to VSCode to properly close the external console after debugging

https://github.com/Microsoft/MIEngine/issues/807

Version: 1.29.1
Commit: bc24f98b5f70467bc689abf41cc5550ca637088e
Date: 2018-11-15T19:07:43.495Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
Architecture: x64

repro

1. debug cpp with external terminal
2. when the program ends, the terminal remains open

"Press any key to continue.." is holding these zombie terminals open (we get a new one with each run/debug run)

[killerkalamari]

I came to report the same problem on the Linux version. This new behavior seemed to coincide with a fix for the Linux terminal emulator selection (before it would always used xterm, regardless of settings... now it respects the setting, defaulting to x-terminal-emulator, but this "Press any key to continue..." thing came along for the ride).

I'm assuming that it was always supposed to be doing this "Press any key" thing in the first place, and that this was a bug that they "fixed" along with fixing the terminal selection problem. However, I wish there were a way for me to disable it, because I end up with numerous lingering terminals during intense debugging sessions. Two of my co-workers also came to me annoyed with it and asking me to see if I can hack around it somehow.

[killerkalamari]

Okay, I've come up with a temporary workaround using python.

1. Create a file named defeat-vscode-pause in the current directory, and add the following code:

#!/usr/bin/env python
# Removes the read statement from the debugging command issued by vscode that
# would otherwise result in a "Press any key to continue..." prompt.
import sys, subprocess
args = sys.argv[:]
args[0] = "x-terminal-emulator"
for arg_i in range(1, len(args)):
    arg = args[arg_i]
    read_i = arg.find("read -p")
    if read_i > -1:
        read_j = arg.find(";", read_i)
        args[arg_i] = arg[:read_i] + arg[read_j + 1:]
        break
rc = subprocess.call(args)
sys.exit(rc)

1. Run:
   chmod +x defeat-vscode-pause
2. Run:
   sudo mv defeat-vscode-pause /usr/local/bin/
3. Open the vscode settings, then click ... and Open settings.json
   Press Ctrl-Shift-P and open Preferences: Open Settings (JSON)
4. Add this line to the settings:
   "terminal.external.linuxExec": "defeat-vscode-pause"

[guoyiteng]

I would like to add that this problem also exists on the internal console. Each debugging session will launch a new terminal and when the program ends, the internal terminal stays open with text

[1] + Done                       "/usr/bin/gdb" --interpreter=mi --tty=${DbgTerm} 0<"/tmp/Microsoft-MIEngine-In-rxo7l3v7.xwx" 1>"/tmp/Microsoft-MIEngine-Out-c3yh2g6c.61r"

After debugging the program for a while, there would be a bunch of internal terminals. I have to manually close all of them, which is pretty annoying. Sadly, the workaround @killerkalamari mentioned does not work for the internal terminal.

This problem only happens on Linux. The internal terminal on macOS could exit after the program ends.

[pingala98]

@guoyiteng please let me know if you find any workaround, for someone who does competitive programming on vs code like me, it is VERY MUCH ANNOYING to close 2 terminal tabs after each debug session.

[therocode]

Same here, after debugging for a while, I have 20+ terminals and VS Code even gives an error at 25 terminals because it's not allowed to allocate any more (on Windows 10 here). Would be good if running the program again reused the terminal

[hammypants]

+1 from me, would be nice to not have to manually kill terminals
(using codelldb)

[connor4312]

@weinand I notice we 'intentionally' add && wait and the like to terminals. Should we remove that wholesale, or or make it a user option? I.e. is this actually a feature request for a setting, or a change in default behavior?

[killerkalamari]

I hope it can be a setting, because I end up turning off my workaround sometimes when I've really messed things up and need to see why it crashed.

[connor4312]

Maybe a better approach would be to kill any existing integrated terminal (for the same configuration?) when launching a new session, so that you would just have 1 extra terminal hanging around, not 100.

[weinand]

@connor4312

• just a clarification: this issue is about the external terminal, not the integrated terminal
• driving external terminals from VS Code on different platforms is challenging. For instance we couldn't find a way on all platforms to reuse an external terminal for multiple sessions because most APIs only support to pass a single shell command on terminal creation. So feeding additional commands into an existing terminal is difficult. Exception: the "Terminal" application on macOS provides AppleScript API for determining whether a terminal is "busy" and for feeding additional input. But the more popular "iTerm" application does not provide the same AppleScript API...
• initially we were closing the terminal immediately at the end of a debug session but with that behavior user complained that they couldn't see runtime errors or program output. That's the reason why the "Press any key to continue..." && wait was added. IIRC the idea was to keep the terminal open if there are issues (exit code != 0) and to close it otherwise.

---

Yes, killing the "previous" terminal when creating a "new" terminal sounds like a good approach to avoid accumulating lots of terminals. But we need to be careful not to kill terminals that are still in use. Using the "configuration name" as a way to find terminal candidates that can be closed only works, if we continue to prevent that launch configs are launched multiple times (but we are planning to lift this - see #110226).