TerminalOptions.waitOnExit API

[Tyriar]

enum WaitOnExitType {
    Never = 0,
    NonZeroExitCode = 1,
    Always = 2
}

export interface TerminalOptions {
    /**
     * Whether the terminal panel should wait before closing when a terminal's process exits.
     */
    waitOnExit?: WaitOnExitType;
}

waitOnExit was originally proposed as a boolean in #15583

[Eskibear]

Looking forward to the API. I don't know why it was commented out before.

https://github.com/Microsoft/vscode/blob/5688d00dd592a165530a82945c4ade4dad6b01e7/src/vs/workbench/api/node/extHostTerminalService.ts#L305

[Tyriar]

@Eskibear it was commented out because we were planning on moving tasks to an extension but ended up changing our minds. I'm interesting in what your use case is?

[Eskibear]

I'm working to enable debugging plugin goal of a Maven project, leveraging Java Debugger extension. The workflow is:

1. create a terminal with env MAVEN_OPTS injected, which specifies the listening port (a random free port).
2. send the maven command to the terminal, then the command will run in debug mode.
3. start a Java debug session, attach to the port.

After terminating the debug session, users may still want to re-visit the diagnostic info printed, so I want to i) persist the printed info there. But as the injected env will force all maven commands to run in debug mode, I also want to ii) prevent users from re-using the terminal.

[Tyriar]

No plans to add this as there is not enough need, for the maven case tasks might be a better option.

[vscodebot]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[twadleigh]

One fairly general use for this functionality is to be able to see a stack trace or other diagnostics from a terminal process that crashes. That was the original motivation for referencing julia-vscode/julia-vscode#653.

[Tyriar]

@twadleigh can you describe a little more how Julia uses/launches the terminal? Is launching a Julia shell and sending text an alternative?

[twadleigh]

@Tyriar you can see the way the julia-vscode extension launches the julia process in the terminal here.

Can you possibly describe more about what you mean by launching a shell and sending text? I initially proposed a solution that wrapped the julia process in a monitor process to intercept the crash, but it was rejected as too heavyweight.

[Tyriar]

@twadleigh Julia is a shell that can also run files right? My proposal was doing something like this:

const t = window.createTerminal({
  shellPath: 'julia.exe'
});
t.sendText('the file/code to run inside the shell');

After run it would leave a shell hanging though.

[Tyriar]

Some asks:

• Julia REPL process wrapper to show errors julia-vscode/julia-vscode#1560
• PowerShell Get stderr or last few lines of extension-owned Terminal in API when it crashes? #91016

[pfitzseb]

Any chance to restart the implementation of/discussion around this feature?

FWIW, what we want for the Julia extension matches the task-backed terminals very well -- the terminal lifecycle is decoupled from the underlying process and we get terminal recycling for free. Tasks feel like the wrong tool for the job though, and there are issues with e.g. Tasks: Rerun last task (even when the task isn't registered).

[m-hilgendorf]

Would also like to bump this FR - currently our workaround for the stanza REPL is to invoke it through a secondary launcher process which waits to exit on input.