Please support "console" Property in launch.json

[yjlin0224]

Please support "console" Property in launch.json, which have "none", "integratedTerminal", "externalTerminal" three Value like python's, and I can debug my go project at outside console and also support standard input.

[thomasdarimont]

I think the relevant code in the python vs code extension is here:
https://github.com/DonJayamanne/pythonVSCode/blob/2cf147caea17f2e2f4818a91628f83c2dcf344ec/src/client/debugger/DebugClients/LocalDebugClient.ts#L109

[Knasinski]

Ditto to item 1

[edburns]

Any word on this? I'm just running into this now.

[varun1729]

Any updates? @ramya-rao-a Here due to 219

[ramya-rao-a]

@varun1729 No updates yet. PRs are welcome if anyone knows how to make this work using the delve apis.

[jakenvac]

I think this might be a limitation of delve as the go extensions for Atom seem to have the same issue.
Doing a google search for Delve stdin also returns various posts about the inability to use stdin while debugging with delve regardless of editor.

[lirao]

@ramya-rao-a The corresponding issue in the delve repository (https://github.com/derekparker/delve/issues/65) has been closed since May, but after I've updated my delve to latest master, using it with vscode debug results in error messages instead of no response:

TypeError: Cannot read property 'currentGoroutine' of null
    at GoDebugSession.evaluateRequest (/Users/rli/.vscode/extensions/ms-vscode.go-0.6.85/out/src/debugAdapter/goDebug.js:774:41)
    at GoDebugSession.dispatchRequest (/Users/rli/.vscode/extensions/ms-vscode.go-0.6.85/node_modules/vscode-debugadapter/lib/debugSession.js:416:22)
    at GoDebugSession._handleData (/Users/rli/.vscode/extensions/ms-vscode.go-0.6.85/node_modules/vscode-debugadapter/lib/protocol.js:97:38)
    at Socket.inStream.on (/Users/rli/.vscode/extensions/ms-vscode.go-0.6.85/node_modules/vscode-debugadapter/lib/protocol.js:18:44)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)

Does this mean this feature can finally get supported?

BTW the usage instructions is here: https://github.com/derekparker/delve/issues/1274#issuecomment-406969034. I've tried on a terminal and it works! You have to fiddle between two terminals, but in vscode-go this can be hidden behind the interface right?

[ramya-rao-a]

@lirao That error message is from evaluateRequest which is fired only when you type something in the debug console. The purpose of that is to evaluate expressions and not to send input to delve. You can think of the its counterpart in delve to be the print command.

I've not looked into supporting the terminal when debugging yet. When I do, I'll get back here.

Meanwhile, others are most welcome to check out the missing pieces and investigate the missing gaps.
https://github.com/Microsoft/vscode-go/wiki/Building,-Debugging-and-Sideloading-the-extension-in-Visual-Studio-Code has the instructions to get started.

[lirao]

I'm not really looking into VSCode supporting the terminal (if I want to use the terminal I could just use the terminal) I'm interested in just debugging go code with interactive stdin input. A few months ago this wasn't even possible even on delve natively, so vscode can't possibly support this. But now that this mechanism is there in delve itself, when will vscode make use of it?

[ramya-rao-a]

I'm not really looking into VSCode supporting the terminal (if I want to use the terminal I could just use the terminal) I'm interested in just debugging go code with interactive stdin input.

@lirao I believe you have misunderstood my statement. I did not mean just "using the terminal". I meant using the terminal to run delve such that it can take in stdin. See https://code.visualstudio.com/updates/v1_5#_additions-to-the-debug-protocol

But now that this mechanism is there in delve itself, when will vscode make use of it?

Have you given this a try in the terminal? I followed the instructions in https://github.com/derekparker/delve/issues/1274#issuecomment-406969034. In the second terminal, delve starts in the "client" mode and so accepts only delve commands not stdin. Am I missing something?

[lirao]

It's how they implemented it (that's why it's a bit wonky). One dlv connect terminal starts the delve session, and accepts only delve commands. The other terminal starts the dlv --headless debug yourprogram.go and reads stdin. (Quoting the comment I linked, "Input for delve will go in the second terminal, input for your program will go in the first one.")

I'm not familiar with the code base, and so I'm not certain if this is something that should be implemented in the plugin as runInTerminal. The integrated terminal in VScode does have a space for stdin input, right? I'm really hoping to use that.

[francoisgergaud]

I am pretty new to Go and just ran in this problem while trying to run some examples from the tcell library.
As a short-term solution, it is possible to run the headless delve debugger in a terminal:
dlv debug --headless --listen=:2345 --log --api-version=2
and then have a configuration in the VSCode´s launch.json file which starts the code to debug in remote debugger like this:

{
    "name": "My remote debug",
    "type": "go",
    "request": "attach",
    "mode": "remote",
    "remotePath": "${workspaceFolder}",
    "port": 2345,
    "host": "127.0.0.1"    
}

Documention about vscode-go remote debugger.

[quoctruong]

@abc1236762 Delve currently does not support reading from stdin so I don't know how valuable it will be to add support for "console" property in launch.json. I think the remote solution that @francoisgergaud has is the best here.

[A-UNDERSCORE-D]

The remote works but is pretty bad UX at best -- Things like stop on the "local" side doesn't stop the remote dlv instance, and having to go though multiple steps to start a debug session (in my case starting a build and only THEN starting a debug session in vscode)

Could adding the console option and automatically working this out in the background be an option? I'm not too sure of the internals, but something as simple as allowing console, but then not allowing manual input via the debug console? that input could go to the headless dlv instance instead

[martijn]

For me, this is not about delve reading from stdin. It's about debugging interactive applications.

My current workaround is starting my binary in the terminal myself and then connecting the debugger using the standard "Attach to Process". This works as you'd expect; my application still responds to user input and the deubgger features in vscode work as well.

I don't understand why a console argument couldn't work for Go like it does for other languages. All it seemingly does is start the binary in the terminal instead of the debug console?

[A-UNDERSCORE-D]

Same here, my software has an interactive command line.

As a workaround I put together some tasks and such to make it only a two step process to start delve in headless mode (to give application stdin access) and then I can start regular debugging in the normal way:

{
    "label": "startgggbdebug",
    "type": "shell",
    "command": "dlv debug --headless --listen :4247 --api-version=2 ${workspaceFolder}/cmd/goGoGameBot.go",
    "group": {
        "kind": "build",
        "isDefault": true
    },
},

which I can start with crtl+shift+b, wherein my software's stdin/out is acessable(after I start a debug)

and debug is configured to run a killdebug task once I ask it to exit, which looks like this:

{
    "label": "killgggbdebug",
    "type": "shell",
    "command": "pkill -f --exact \"dlv debug --headless --listen :4247 --api-version=2 ${workspaceFolder}/cmd/goGoGameBot.go\"",
    "presentation": {
        "echo": true,
        "reveal": "never",
        "focus": false,
        "panel": "shared",
        "showReuseMessage": false,
        "clear": false
    }
}

This is still a hack around something that the plugin's competitor (goland) has done (I believe by doing essentially the same as the above, but transparently to the user)

This seems like something that could be quite easily added to the plugin itself without requiring users to go to this extra effort.

EDIT: As an update to the above, I must note that you can not add the start task as a pre-launch task, as vscode waits for an exit from pre-launch tasks before starting the main.

[ramya-rao-a]

Hello all,

We are in the midst of a repo move, see We are moving section in our readme for more details.

Closing this issue in favor of golang/vscode-go#124. Please subscribe to it for further updates and upvote it as well. Unfortunately, we could not transfer the issue across Github orgs, therefore could not move the upvotes this feature request has acquired over time.

Thanks for all the support & Happy Coding!