According to the Windows documentation:

The SetConsoleMode function can disable the ENABLE_PROCESSED_INPUT input mode for a console's input buffer, so CTRL+C is reported as keyboard input rather than as a signal.

In the windows implementation, we do:

var newMode uint32
newMode &^= windows.ENABLE_ECHO_INPUT
newMode &^= windows.ENABLE_LINE_INPUT
newMode &^= windows.ENABLE_MOUSE_INPUT
newMode &^= windows.ENABLE_WINDOW_INPUT

newMode &^= windows.ENABLE_PROCESSED_INPUT // This reports CTRL+C as an input rather than as a signal.

newMode |= windows.ENABLE_EXTENDED_FLAGS
newMode |= windows.ENABLE_INSERT_MODE
newMode |= windows.ENABLE_QUICK_EDIT_MODE

I believe it should be changed to newMode |= windows.ENABLE_PROCESSED_INPUT so we keep the signal propagation.

hello, i found this problem when using bubbletea.

test code:

func main() {
	test(os.Stdin)

	reader, _ := cancelreader.NewReader(os.Stdin)
	test(reader)
}

func test(reader io.Reader) {
	var buf [256]byte
	n, err := reader.Read(buf[:])
	if err != nil {
		fmt.Println(err)
	}

	r, _ := utf8.DecodeRune(buf[:n])
	fmt.Println("decode error ? ", r == utf8.RuneError)
	fmt.Printf("%s \n", string(r))
	fmt.Println(buf[:n])

	fmt.Println("=============")
}

input: 好
output:

$ go run .
好
decode error ?  false
好
[229 165 189 13 10]
=============
decode error ?  true
�
[186 195]
=============

go version go1.19 windows/amd64 faild
go version go1.18 windows/amd64 falid

but it was successful on go version go1.18.3 linux/amd64

This package was exactly what I needed to solve a tricky issue in my code.

On Windows, NewReader(os.Stdin) will replace stdin with a handle to the console, even when stdin was previously redirected from a pipe.

This can be fixed by returning newFallbackCancelReader(reader) when stdin is not a console.