Unable to read stdin input in debug mode

[zonghaishang]

I am a go language enthusiast and I am just getting started.
Here is my question:
In debug mode, the program is blocked in stdin and cannot be entered.

1. What version of Delve are you using (dlv version)?

Delve Debugger
Version: 1.0.0
Build: 86120a3b4038318b08c2898059733a7bf1499ee5

2. What version of Go are you using? (go version)?

go version go1.9.3 darwin/amd64

3. What operating system and processor architecture are you using?

Darwin yiji.local 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64

4. What did you do?
   In debug mode, the program is blocked in stdin and cannot be entered.

5. What did you expect to see?
   The program receives input and the debug runs normally.

6. What did you see instead?
   Here is my simple code :

package main

import (
	"bufio"
	"os"
	"fmt"
)

func main()  {
	input := bufio.NewScanner(os.Stdin)
	words := make(map[string]int)
	for input.Scan() {
		fmt.Println("Received:" + input.Text())
		if len(input.Text()) <= 0 {
			break
		}
		words[input.Text()]++
	}

	for word, n := range words {
		if n > 1 {
			fmt.Printf("%d %s\n", n, word)
		}
	}
}

Is this a bug?

[aarzilli]

So far the only supported way to debug a program like this is to start a headless instance in one terminal:

dlv --headless debug yourprogram.go

This will print something like this:

API server listening at: 127.0.0.1:XYZ

then in another terminal do:

dlv connect :XYZ

Input for delve will go in the second terminal, input for your program will go in the first one.

Duplicate of #65

[zonghaishang]

I have tried, but no working.

[zonghaishang]

firtst tab:

➜  dump1 git:(master) ✗ dlv --headless debug
API server listening at: 127.0.0.1:56957
debugserver-@(#)PROGRAM:debugserver  PROJECT:debugserver-900.0.64
 for x86_64.
Got a connection, launched process /Users/Jason/opensource/go-learning/chap1/dump1/debug (pid = 87013).

[aarzilli]

Input for delve will go in the second terminal, input for your program will go in the first one.

[zonghaishang]

@aarzilli Please reopen this issue, thanks.

[zonghaishang]

It works, thanks, This treatment is not elegant, will it improve in the future?

[aarzilli]

It works, thanks, This treatment is not elegant, will it improve in the future?

Highly unlikely. Debugging like this is of little practical use.

[AaronViviano]

Hello Delve Developers,
I would like to note I've run into this issue in my own development efforts. Being able to debug with console input is a fundamental basic tool in writing applications. An attempt to look into this issue again would be appreciated.

Regards,
Aaron

[marcel-aan-zee]

The argument I've read on slack is not correct in my opinion.

imho it's a bad idea to interact with the program you are debugging, you should set up something to reproduce the problem automatically

What happens if a program you've made just has a bug and you want to do the same as the user did?
You start the program (via VSC) with debug, but... the debugger stops when the user input is wanted.
I would love to see a fix for this (and not a workaround)

[daniel-santos]

Highly unlikely. Debugging like this is of little practical use.

I suggest you examine the number of downvotes this comment has gotten. As a programmer of 35-odd years, I can assure you that you are quite mistaken. Note that people write different types of programs. Maybe you may not find yourself writing such code, but this idiom is what UNIX was built upon: piping data from one program to another. In my case, I'm debugging a protocol buffers generator plugin that communicates via a pipe.

[aarzilli]

Maybe you may not find yourself writing such code, but this idiom is what UNIX was built upon: piping data from one program to another. In my case, I'm debugging a protocol buffers generator plugin that communicates via a pipe.

You can do that with -r and process substitution. See 7555d1c