Get stderr or last few lines of extension-owned Terminal in API when it crashes?

[rjmholt]

I've read through #78574 and #62103, but please feel free to let me know if this is a duplicate or unfeasible.

Every so often we get an issue opened on the PowerShell extension like this one where the subprocess we start as a terminal crashes before we can log anything.

In those cases, it's currently quite hard to work out why the terminal crashed. We either need the user to run the invocation we pass to VSCode to start the terminal, or get them to record a GIF of the crash when they reproduce it to capture the brief moment the error message is displayed in the terminal before it's cleaned up.

If it were possible for us to get the stderr or the most recent output of the terminal in some way, we'd be able to log the error and probably have a significantly improved rate of error fixing and user satisfaction. I understand that ask is vague and there are performance implications with reading everything as it comes through and so on, but just want to express the general desire to see more than the exit code when a terminal process crashes. And query whether that's:

1. Already possible
2. Infeasible
3. Possibly implementable with some set of caveats

[Tyriar]

So as I understand it we cannot differentiate between stderr and stdout since the messages are just coming over a single pipe, at least without complicating things a bunch (this has been discussed before microsoft/node-pty#71).

As for getting the last few lines of output, right now no extensions can access the terminal output kind of by design. There's a proposed-only API that gets at output (onDidWriteTerminalData) that live share uses but there are performance/security issues with it that we're not willing to accept for general use.

One thought is to expose the terminal buffer similar to TextDocument but the problem there is that the APIs would have to be asynchronous as the terminal doesn't mirror the buffer in the extension host (and definitely should not), but making it async would be inconsistent with TextDocument 😕. If you have any bright ideas on how to expose just the needed context I'm all ears, hard coding a magic number seems bad as people will just keep requesting the number be higher/configurable.

[pfitzseb]

An alternative might be to add a closeTerminalOnProcessExit: 'always' | 'zero-exit' | 'never' option for window.createTerminal. That way an extension can create a terminal that stays open even if the underlying process dies; the user can then still look at all output.

[Tyriar]

This is essentially asking for #70444

/duplicate