launch.json - add option for logging stdout/stderr to file

[stellarpower]

My application dumps useful information to stdout / stderr when I run it. When debugging, I'd like to be able to copy this to a file automatically, rather than need to use some wort of wrapper script that calls tee, copy-paste from the output console, or run separately to capture this. There may well be an existing workaround, but as this is quite a simple and I imagine commonly useful feature request, I think it would be nice to add support for it on its own.

I'd propose adding an option similar ot this to launch.json, most likely keeping it simple as it's a pretty trivial addition:

// ...
configurations: [{
    "name": "Foo",
    "type": "cppdbg",
    "request": "launch",
    "program": "${workspaceFolder}/main",

    // ...
    "log": {
        "stdout": "/path/to/file.out"
        "stderr": "/path/to/file.err"
        "stdin":  "/path/to/file.in" // Optional - capture anything typed into the run console.
     }
    // ...
        },
// ...

[weinand]

@stellarpower in theory this feature request sounds simple to implement but in reality it is difficult.

The problem is that VS Code knows nothing about "stdout/stdin/stderr" of the debuggee because only the debug extension controls the debuggee and "knows" if it supports "stdout/stdin/stderr" and whether it is possible to redirect "stdout/stdin/stderr" to/from a file.

So in your case the C/C++ extension would be in a much better position to implement that feature. I suggest to file a feature against the C/C++ extension too.

[stellarpower]

Thanks for the fast response!

Afraid I'm not sure I understand, what do you mean by if the debuggee supports stdout/stdin/stderr? Every process forked ought to have at least these file descriptors opened I believe.

Presumably for any extenson being used to debug, if it outputs something to the integrated console as part of this it'd need to get access to the console in the same way as a different extension, wouldn't it?

[weinand]

@stellarpower VS Code does not know anything about "forked processes". It is the debug extension that might fork the debuggee. But when debugging Javascript running in a browser, or when attaching a debugger to an already running process, there is no need to "fork a process" and as a consequence there is nothing like "stdout/stdin/stderr".

If a debug extension starts a debuggee in the integrated (or external) terminal, then the debuggee's "stdout/stdin/stderr" are managed directly by the integrated terminal's shell. In this case not even the debug extension sees the input/output to/from "stdout/stdin/stderr". Only if the debuggee is launched in the debug console, has the debug extension a chance to see the stdout/stderr (but not even stdin, a missing piece currently discussed in microsoft/debug-adapter-protocol#216).

[stellarpower]

So, in that case, would it be possible to wrap the shell that is running in the integrated or external terminal? Ultimately for text to appear in the terminal for the debugging process, it must have access to a stream at this point. I think dumping that would be sufficient to achieve this goal, although granted there may be many steps inbetween that make it ugly to perform in code itself. 17 Jan 2022 16:27:42 Andre Weinand ***@***.***>:

…

@stellarpower[https://github.com/stellarpower] VS Code does not know anything about "forked processes". It is the debug extension that might fork things. But when debugging Javascript running in a browser, or when attaching a debugger to an already running process, there is no need to "fork a process" and as a consequence there is nothing like "stdout/stdin/stderr". If a debug extension starts a debuggee in the integrated terminal (or external terminal), then debuggee's "stdout/stdin/stderr" are managed directly by the integrated terminal's shell. In this case not even the debug extension sees the input/output "stdout/stdin/stderr". Only if the debuggee is launched in the debug console, has the debug extension a chance to see the stdout/stderr (but not even stdin). — Reply to this email directly, view it on GitHub[#140859 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ABGF2APHAGPMWCUWVWMILMDUWQ7P3ANCNFSM5MEXVAMQ]. You are receiving this because you were mentioned. [data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEgAAABICAYAAABV7bNHAAAAAXNSR0IArs4c6QAAAARzQklUCAgICHwIZIgAAAArSURBVHic7cEBDQAAAMKg909tDjegAAAAAAAAAAAAAAAAAAAAAAAAAAA+DFFIAAEctgHwAAAAAElFTkSuQmCC###24x24:true###][Tracking image][https://github.com/notifications/beacon/ABGF2AJWHPR4UUAUVUDJNQTUWQ7P3A5CNFSM5MEXVAM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHR5U3KQ.gif]

[weinand]

Yes, the command that is used to run the debuggee in the shell could redirect "stdout/stdin/stderr". But this command is an implementation detail of the debug extension and not controlled by VS Code, so VS Code can not support this generically. So only the debug extension could implement this.

What makes things complex on that front is the fact that for many debuggers the debuggee is not directly launched in the shell but indirectly from within a command line debugger like "gdb". Redirecting "stdout/stdin/stderr" of "gdb" does not help redirecting "stdout/stdin/stderr" of the debuggee.

Bottom line: don't hold your breath while waiting for VS Code to implement this feature anytime soon - it is more realistic that individual debug extensions will implement that feature.

[weinand]

@stellarpower vscode-lldb supports stdio redirection already as part of the launch configuration: https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#stdio-redirection