starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Preview: Inconsistent Behavior When Writing to Stdout While Reading From Stdin #22607

New Issue
Open
opened 2026-01-31 08:18:20 +00:00 by claunia · 11 comments
claunia commented 2026-01-31 08:18:20 +00:00
Owner
Copy Link

Originally created by @CannibalVox on GitHub (Dec 1, 2024).

Windows Terminal version

1.22.3232.0

Windows build number

10.0.19045.5131

Other Software

WSL seems to work fine, but other hosted terminals have this issue. To be clear, this only happens with the preview version of WT. The stable version works fine.

Steps to reproduce

Create any program that begins reading from stdin and then after reading has begun, write to stdout. Here is an example program in golang:

package main

import (
	"bufio"
	"fmt"
	"os"
	"os/signal"
	"syscall"
	"time"
)

func DoScan() {
	scanner := bufio.NewScanner(os.Stdin)
	scanner.Split(bufio.ScanRunes)

	for scanner.Scan() {
		fmt.Print(scanner.Text())
	}
}

func main() {

	go DoScan()
	time.Sleep(1)

	fmt.Print("Here is a prompt! >")

	sigs := make(chan os.Signal, 1)
	signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM)

	<-sigs
}

Expected Behavior

I expected that my typed keys would appear after the caret of the prompt output. That's what it does in the stable version of WT and that's what it does in WSL even in the preview version.

Actual Behavior

My typed keys appear at the beginning of the line, overwriting the prompt.

Originally created by @CannibalVox on GitHub (Dec 1, 2024). ### Windows Terminal version 1.22.3232.0 ### Windows build number 10.0.19045.5131 ### Other Software WSL seems to work fine, but other hosted terminals have this issue. To be clear, this only happens with the preview version of WT. The stable version works fine. ### Steps to reproduce Create any program that begins reading from stdin and then after reading has begun, write to stdout. Here is an example program in golang: ```go package main import ( "bufio" "fmt" "os" "os/signal" "syscall" "time" ) func DoScan() { scanner := bufio.NewScanner(os.Stdin) scanner.Split(bufio.ScanRunes) for scanner.Scan() { fmt.Print(scanner.Text()) } } func main() { go DoScan() time.Sleep(1) fmt.Print("Here is a prompt! >") sigs := make(chan os.Signal, 1) signal.Notify(sigs, syscall.SIGINT, syscall.SIGTERM) <-sigs } ``` ### Expected Behavior I expected that my typed keys would appear after the caret of the prompt output. That's what it does in the stable version of WT and that's what it does in WSL even in the preview version. ### Actual Behavior My typed keys appear at the beginning of the line, overwriting the prompt.
claunia added the Issue-BugNeeds-Tag-FixProduct-TerminalArea-CookedRead labels 2026-01-31 08:18:21 +00:00
claunia commented 2026-01-31 08:18:22 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Dec 11, 2024):

Thanks for filing! Though this worked on the stable version, we recommend against your scenario "reading from stdin and then after reading has begun, write to stdout". It's not something that can be guaranteed to work if you're using line buffered stdin (the default behavior; with the other modes being "unbuffered stdin" aka "raw mode").

We're also missing a real world use case. What's an application that's doing this today and is impacted by the change? With that, we can reconsider working on this.

As such, closing as not planned.

@carlos-zamora commented on GitHub (Dec 11, 2024): Thanks for filing! Though this worked on the stable version, we recommend against your scenario "reading from stdin and then after reading has begun, write to stdout". It's not something that can be guaranteed to work if you're using line buffered stdin (the default behavior; with the other modes being "unbuffered stdin" aka "raw mode"). We're also missing a real world use case. What's an application that's doing this today and is impacted by the change? With that, we can reconsider working on this. As such, closing as not planned.
claunia commented 2026-01-31 08:18:22 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 12, 2024):

We're also missing a real world use case. What's an application that's doing this today and is impacted by the change? With that, we can reconsider working on this.

It's literally just reading from stdin and writing to stdout. You're saying that I need to stop reading from stdin every time I write to stdout on windows terminal?!?!

There are also issues in raw mode, not just line reading mode. The cursor will do this funky thing where it jiggles back and forth when you echo characters to the terminal.

@CannibalVox commented on GitHub (Dec 12, 2024): > We're also missing a real world use case. What's an application that's doing this today and is impacted by the change? With that, we can reconsider working on this. It's literally just reading from stdin and writing to stdout. You're saying that I need to stop reading from stdin every time I write to stdout on windows terminal?!?! There are also issues in raw mode, not just line reading mode. The cursor will do this funky thing where it jiggles back and forth when you echo characters to the terminal.
claunia commented 2026-01-31 08:18:22 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 12, 2024):

Doesn't this pretty badly undermine the utility of conpty considering that this behavior works on every other terminal and also works on WT if I read from the old console libraries instead of the pty?

@CannibalVox commented on GitHub (Dec 12, 2024): Doesn't this pretty badly undermine the utility of conpty considering that this behavior works on every other terminal and also works on WT if I read from the old console libraries instead of the pty?
claunia commented 2026-01-31 08:18:22 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 12, 2024):

Like I feel like there's been a miscommunication here, because the go programming language doesn't even have the ability to cancel a read from stdin so what you are recommending isn't even possible on any application written in that language.

@CannibalVox commented on GitHub (Dec 12, 2024): Like I feel like there's been a miscommunication here, because the go programming language doesn't even have the ability to cancel a read from stdin so what you are recommending isn't even possible on any application written in that language.
claunia commented 2026-01-31 08:18:22 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 12, 2024):

Description of the new feature

In #18265 @carlos-zamora informed me that while operating the terminal as full duplex (reading from stdin and writing to stdout at the same time) does work in the stable version of Windows Terminal, Microsoft did not recommend doing so, so a bug with full duplex operation was not actually a bug.

Given that the last half-duplex terminal to exist was decommissioned sometime in the 1990s, however, I suggest that Microsoft undergo a project to add full duplex operation to Windows Terminal. And bring it into line with similar products. While Carlos did not believe there were any known use cases for a full duplex terminal, I'm inclined to disagree. While I can't speak for anyone else, the Go programming language does not have the capability to cancel reading from stdin, meaning that no application written in Go is capable of half-duplex operations. I believe that adding Full Duplex capability to Windows Terminal would be a major boon for Go developers, especially since we all thought Windows Terminal already had it.

Proposed technical implementation details

I'm not clear on the technical specifics, but probably do whatever the current version of Windows Terminal does, since Full Duplex works in that version.

@DHowett commented on GitHub (Dec 12, 2024): > ### Description of the new feature > In [#18265](https://github.com/microsoft/terminal/issues/18265) [<img alt="" width="16" height="16" src="https://avatars.githubusercontent.com/carlos-zamora?size=32">@carlos-zamora](https://github.com/carlos-zamora) informed me that while operating the terminal as full duplex (reading from stdin and writing to stdout at the same time) does work in the stable version of Windows Terminal, Microsoft did not recommend doing so, so a bug with full duplex operation was not actually a bug. > > Given that the last half-duplex terminal to exist was decommissioned sometime in the 1990s, however, I suggest that Microsoft undergo a project to add full duplex operation to Windows Terminal. And bring it into line with similar products. While Carlos did not believe there were any known use cases for a full duplex terminal, I'm inclined to disagree. While I can't speak for anyone else, the Go programming language does not have the capability to cancel reading from stdin, meaning that no application written in Go is capable of half-duplex operations. I believe that adding Full Duplex capability to Windows Terminal would be a major boon for Go developers, especially since we all thought Windows Terminal already had it. > > ### Proposed technical implementation details > I'm not clear on the technical specifics, but probably do whatever the current version of Windows Terminal does, since Full Duplex works in that version.
claunia commented 2026-01-31 08:18:23 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Dec 12, 2024):

Carlos' comment above is the result of a fairly lengthy discussion internally that day. I also apologize if the shortened response we wrote together seemed like we tried to smother this discussion. That wasn't our intention.

The default mode of input for a terminal is "line-oriented", "line-buffered", or how Windows calls it: "cooked". This means that only when you press Enter, the input is flushed and sent to the application. Until then, the application will not see the input.

It also has the "echo mode" enabled, which means that the terminal driver sends every input character immediately back to the terminal, before the application even sees that input.

So, just to be clear, as I'm not sure if you did this intentionally, the following code does not disable line-oriented input. All it does is change the way the scanner splits the input. It's still only flushed to your Go application when you press enter:

scanner.Split(bufio.ScanRunes)

That aside, from a technical POV what you're doing isn't strictly correct on any operating system, UNIX included. This is because the echo mode you left enabled returns input to the terminal "immediately" while your application will see that input only asynchronously. They're not in sync. If your application lags, your output will be mixed with the already echoed output by the terminal driver, no matter what OS you run your application on.

Windows is a special case. Its line-oriented input is more akin to the GNU readline() function, because it offers "advanced" input functionality, like command history, word-wise cursor navigation, pagination, and so on. And just like readline(), it does not work when the application prints text after the readline call (the line-oriented read) was initiated, because in order to have these features it must make more assumptions (namely: the cursor does not move after the read started). Have you ever wondered why you can't backspace onto a previous line in line-oriented reads under UNIX while it works on Windows? This is why.

In short: Your code is technically incorrect on any OS, but it'll be a very subtle and rare defect on UNIX, while it is an obvious issue on Windows, because our line-oriented input is more feature-rich, like readline().

The issue you have can be hot-fixed, but the problem is that it only fixes your exact, specific issue. If you change your repro to, for instance, continuously print text, it'll be broken again. That's why we asked what scenario exactly your issue is about, because we wanted to estimate whether it's worth hot-fixing it, despite the hot-fix not actually fixing the overarching issue.

Lastly, if you want character-by-character input you can disable line-oriented input and switch stdin into the "raw mode" (mentioned previously). This causes the terminal to immediately send you each character that's typed in and lets you do the full-duplex stdin/stdout that you want. For it to properly work though, you'd have to disable the "echo mode" as well, because of the race condition mentioned above. Coincidentally, enabling raw mode and disabling echo mode is exactly how most shells work, with the exception of cmd.exe.

(Edit: I saw you mention that the cursor jiggles. We've seen that reported for cygwin before and very specific zsh extensions under WSL, but we haven't seen a good repro yet that would help us investigate this. If you have a simple repo, please let us know!)

@lhecker commented on GitHub (Dec 12, 2024): Carlos' comment above is the result of a fairly lengthy discussion internally that day. I also apologize if the shortened response we wrote together seemed like we tried to smother this discussion. That wasn't our intention. The default mode of input for a terminal is "line-oriented", "line-buffered", or how Windows calls it: "cooked". This means that only when you press Enter, the input is flushed and sent to the application. Until then, the application will not see the input. It also has the "echo mode" enabled, which means that the terminal driver sends every input character immediately back to the terminal, before the application even sees that input. So, just to be clear, as I'm not sure if you did this intentionally, the following code does not disable line-oriented input. All it does is change the way the scanner splits the input. It's still only flushed to your Go application when you press enter: ```go scanner.Split(bufio.ScanRunes) ``` That aside, from a technical POV what you're doing isn't strictly correct on any operating system, UNIX included. This is because the echo mode you left enabled returns input to the terminal "immediately" while your application will see that input only asynchronously. They're not in sync. If your application lags, your output will be mixed with the already echoed output by the terminal driver, no matter what OS you run your application on. Windows is a special case. Its line-oriented input is more akin to the GNU `readline()` function, because it offers "advanced" input functionality, like command history, word-wise cursor navigation, pagination, and so on. And just like `readline()`, it does not work when the application prints text after the readline call (the line-oriented read) was initiated, because in order to have these features it must make more assumptions (namely: the cursor does not move after the read started). Have you ever wondered why you can't backspace onto a previous line in line-oriented reads under UNIX while it works on Windows? This is why. In short: Your code is technically incorrect on any OS, but it'll be a very subtle and rare defect on UNIX, while it is an obvious issue on Windows, because our line-oriented input is more feature-rich, like `readline()`. The issue you have can be hot-fixed, but the problem is that it only fixes your exact, specific issue. If you change your repro to, for instance, continuously print text, it'll be broken again. That's why we asked what scenario exactly your issue is about, because we wanted to estimate whether it's worth hot-fixing it, despite the hot-fix not actually fixing the overarching issue. Lastly, if you want character-by-character input you can disable line-oriented input and switch stdin into the "raw mode" (mentioned previously). This causes the terminal to immediately send you each character that's typed in and lets you do the full-duplex stdin/stdout that you want. For it to properly work though, you'd have to disable the "echo mode" as well, because of the race condition mentioned above. Coincidentally, enabling raw mode and disabling echo mode is exactly how most shells work, with the exception of cmd.exe. (Edit: I saw you mention that the cursor jiggles. We've seen that reported for cygwin before and very specific zsh extensions under WSL, but we haven't seen a good repro yet that would help us investigate this. If you have a simple repo, please let us know!)
claunia commented 2026-01-31 08:18:23 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 13, 2024):

No part of your response really addresses the issue at all, so I feel like I maybe haven't made myself clear. The problem is not that my echo is being interleaved with the output. The problem is that after the output has been written, if I provide any input, the cursor will go back to the beginning of the line instead of my echo beginning where the cursor was left as the text is written.

Running the program will make what I'm talking about abundantly clear, and will make obvious that this is not the issue you are describing. The following steps will reproduce the issue:

  1. Begin reading from stdin.
  2. Write text to stdout but don't include a newline. The cursor will be at the end of the written content.
  3. Start typing letters. Again, note that this does not begin until AFTER the stdout text has been fully written. This is not a synchronization issue between the echo text and the written text, because they are not happening at the same time.

What will occur is that the cursor will return to the beginning of the line where the prompt was written for no apparent reason.

The "jiggling" issue will happen if you do the above program with raw mode on and start echoing text to the terminal manually. When you write for instance BS (\x08) to to the output stream, the cursor will not step back a single position immediately, it will return to the beginning of the line and then snap back to where it's supposed to be.

@CannibalVox commented on GitHub (Dec 13, 2024): No part of your response really addresses the issue at all, so I feel like I maybe haven't made myself clear. The problem is not that my echo is being interleaved with the output. The problem is that after the output has been written, if I provide any input, the cursor will go back to the beginning of the line instead of my echo beginning where the cursor was left as the text is written. Running the program will make what I'm talking about abundantly clear, and will make obvious that this is not the issue you are describing. The following steps will reproduce the issue: 1. Begin reading from stdin. 2. Write text to stdout but don't include a newline. The cursor will be at the end of the written content. 3. Start typing letters. Again, note that this does not begin until AFTER the stdout text has been fully written. This is not a synchronization issue between the echo text and the written text, because they are not happening at the same time. What will occur is that the cursor will return to the beginning of the line where the prompt was written for no apparent reason. The "jiggling" issue will happen if you do the above program with raw mode on and start echoing text to the terminal manually. When you write for instance BS (\x08) to to the output stream, the cursor will not step back a single position immediately, it will return to the beginning of the line and then snap back to where it's supposed to be.
claunia commented 2026-01-31 08:18:23 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 13, 2024):

Here's a loom video so you can see the program in action: https://www.loom.com/share/b79fe88bbef04862869f8c5a9f69cd11?sid=d0984f9e-3309-4ce0-a9a3-612e3ac4f9cc

@CannibalVox commented on GitHub (Dec 13, 2024): Here's a loom video so you can see the program in action: https://www.loom.com/share/b79fe88bbef04862869f8c5a9f69cd11?sid=d0984f9e-3309-4ce0-a9a3-612e3ac4f9cc
claunia commented 2026-01-31 08:18:23 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Dec 13, 2024):

The problem is not that my echo is being interleaved with the output. The problem is that after the output has been written, if I provide any input, the cursor will go back to the beginning of the line instead of my echo beginning where the cursor was left as the text is written.

But I wrote about more than just the echo mode. I wrote multiple paragraphs about how Windows' line-oriented input is more akin to GNU readline, that I thought would apply very well. If you tell me why those don't apply to your issue, I'd be able to write a better response, or perhaps come to a different conclusion for myself.

This code should demonstrate what I meant:

package main

import (
	"fmt"
	"time"
)

/*
#cgo LDFLAGS: -lreadline
#include <stdio.h>
#include <readline/readline.h>
*/
import "C"

func main() {
	go func() {
		time.Sleep(50 * time.Millisecond)
		fmt.Printf("Here is a prompt! >")
	}()
	C.readline(C.CString(""))
}

This is how it looks like:

https://github.com/user-attachments/assets/8e5e14df-c678-4524-bba9-0e5f645a2dc0

I only wrote the paragraphs about interleaved output, because "writing to stdout while reading from stdin" has 2 issues, and not just the one that you reported. If I fix the one you found, your code would still be incorrect, and I'd still strongly recommend not writing to stdout while reading from line-oriented stdin.

The "jiggling" issue will happen if you do the above program with raw mode on and start echoing text to the terminal manually. When you write for instance BS (\x08) to to the output stream, the cursor will not step back a single position immediately, it will return to the beginning of the line and then snap back to where it's supposed to be.

Are you compiling the application with native Go for Windows (i.e. not MSYS/Cygwin)? I tried this code, and I don't see any jitter:

package main

import (
	// ... same import ...
	"golang.org/x/sys/windows"
)

func DoScan() {
	scanner := bufio.NewScanner(os.Stdin)
	scanner.Split(bufio.ScanRunes)

	for scanner.Scan() {
		text := scanner.Text()
		if text == "\b" {
			text = "\b \b"
		}
		fmt.Print(text)
	}
}

func main() {
	handle := windows.Handle(os.Stdin.Fd())
	var originalMode uint32
	windows.GetConsoleMode(handle, &originalMode)
	rawMode := originalMode &^ (windows.ENABLE_ECHO_INPUT | windows.ENABLE_LINE_INPUT)
	windows.SetConsoleMode(handle, rawMode)
	defer windows.SetConsoleMode(handle, originalMode)

	// ... same code as in your example ...
}

I've seen the jitter in screen recordings before, and I do want to fix it ASAP, but I can't debug it without having the issue myself. 🥲

Lastly, I wanted to pick up something again that I said before:

The issue you have can be hot-fixed, but the problem is that it only fixes your exact, specific issue. If you change your repro to, for instance, continuously print text, it'll be broken again. That's why we asked what scenario exactly your issue is about, because we wanted to estimate whether it's worth hot-fixing it, despite the hot-fix not actually fixing the overarching issue.

Continuously printing text while reading from a line-oriented stdin is the main scenario I can imagine for why someone would print to stdout after starting the read from stdin. Like, when printing log output and you want to offer the user an interactive input prompt. However, fixing your issue (= printing exactly 1 time, after starting the read) won't fix that or other scenarios at all. That's the primary reason why I hesitate to hotfix it. Outside of the issue description itself, can you say why this should be hotfixed (= moving the issue goal posts)?

@lhecker commented on GitHub (Dec 13, 2024): > The problem is not that my echo is being interleaved with the output. The problem is that after the output has been written, if I provide any input, the cursor will go back to the beginning of the line instead of my echo beginning where the cursor was left as the text is written. But I wrote about more than just the echo mode. I wrote multiple paragraphs about how Windows' line-oriented input is more akin to GNU readline, that I thought would apply very well. If you tell me why those don't apply to your issue, I'd be able to write a better response, or perhaps come to a different conclusion for myself. This code should demonstrate what I meant: ```go package main import ( "fmt" "time" ) /* #cgo LDFLAGS: -lreadline #include <stdio.h> #include <readline/readline.h> */ import "C" func main() { go func() { time.Sleep(50 * time.Millisecond) fmt.Printf("Here is a prompt! >") }() C.readline(C.CString("")) } ``` This is how it looks like: https://github.com/user-attachments/assets/8e5e14df-c678-4524-bba9-0e5f645a2dc0 I only wrote the paragraphs about interleaved output, because "writing to stdout while reading from stdin" has 2 issues, and not just the one that you reported. If I fix the one you found, your code would still be incorrect, and I'd still strongly recommend not writing to stdout while reading from line-oriented stdin. > The "jiggling" issue will happen if you do the above program with raw mode on and start echoing text to the terminal manually. When you write for instance BS (\x08) to to the output stream, the cursor will not step back a single position immediately, it will return to the beginning of the line and then snap back to where it's supposed to be. Are you compiling the application with native Go for Windows (i.e. not MSYS/Cygwin)? I tried this code, and I don't see any jitter: ```go package main import ( // ... same import ... "golang.org/x/sys/windows" ) func DoScan() { scanner := bufio.NewScanner(os.Stdin) scanner.Split(bufio.ScanRunes) for scanner.Scan() { text := scanner.Text() if text == "\b" { text = "\b \b" } fmt.Print(text) } } func main() { handle := windows.Handle(os.Stdin.Fd()) var originalMode uint32 windows.GetConsoleMode(handle, &originalMode) rawMode := originalMode &^ (windows.ENABLE_ECHO_INPUT | windows.ENABLE_LINE_INPUT) windows.SetConsoleMode(handle, rawMode) defer windows.SetConsoleMode(handle, originalMode) // ... same code as in your example ... } ``` I've seen the jitter in screen recordings before, and I do want to fix it ASAP, but I can't debug it without having the issue myself. 🥲 --- Lastly, I wanted to pick up something again that I said before: > The issue you have can be hot-fixed, but the problem is that it only fixes your exact, specific issue. If you change your repro to, for instance, continuously print text, it'll be broken again. That's why we asked what scenario exactly your issue is about, because we wanted to estimate whether it's worth hot-fixing it, despite the hot-fix not actually fixing the overarching issue. Continuously printing text while reading from a line-oriented stdin is _the_ main scenario I can imagine for why someone would print to stdout after starting the read from stdin. Like, when printing log output and you want to offer the user an interactive input prompt. However, fixing your issue (= printing exactly 1 time, after starting the read) won't fix that or other scenarios at all. That's the primary reason why I hesitate to hotfix it. Outside of the issue description itself, can you say why this should be hotfixed (= moving the issue goal posts)?
claunia commented 2026-01-31 08:18:24 +00:00
Author
Owner
Copy Link

@CannibalVox commented on GitHub (Dec 13, 2024):

I understand what you're saying now, and I'm sorry for getting snotty earlier.

Regarding the jiggling issue: I was able to repro it with your code in VSCode before but now I can't. I'll keep an eye out for it as a separate issue.

To be clear about this, go does not offer an input method equivalent to C.readLine, so the following code will also demonstrate the issue:

package main

import (
	"fmt"
	"time"
)

func main() {
	go func() {
		time.Sleep(50 * time.Millisecond)
		fmt.Printf("Here is a prompt! >")
	}()

	var text string 
	fmt.Scanln(&text)
}

The bug doesn't require that stdin is read continuously, just that output is printed while stdin is being read.

Continuously printing text while reading from a line-oriented stdin is the main scenario I can imagine for why someone would print to stdout after starting the read from stdin. Like, when printing log output and you want to offer the user an interactive input prompt. However, fixing your issue (= printing exactly 1 time, after starting the read) won't fix that or other scenarios at all.

That wouldn't even fix my issue, that would just fix the code snippet I made to demonstrate my issue. What I don't agree is with the word "continuous". "Periodically" might be a better word to use. I type something, and then output is printed, and then I type something else. Maybe Go is the only language with this problem, though.

@CannibalVox commented on GitHub (Dec 13, 2024): I understand what you're saying now, and I'm sorry for getting snotty earlier. Regarding the jiggling issue: I was able to repro it with your code in VSCode before but now I can't. I'll keep an eye out for it as a separate issue. To be clear about this, go does not offer an input method equivalent to C.readLine, so the following code will also demonstrate the issue: ```go package main import ( "fmt" "time" ) func main() { go func() { time.Sleep(50 * time.Millisecond) fmt.Printf("Here is a prompt! >") }() var text string fmt.Scanln(&text) } ``` The bug doesn't require that stdin is read *continuously*, just that output is printed while stdin is being read. > Continuously printing text while reading from a line-oriented stdin is the main scenario I can imagine for why someone would print to stdout after starting the read from stdin. Like, when printing log output and you want to offer the user an interactive input prompt. However, fixing your issue (= printing exactly 1 time, after starting the read) won't fix that or other scenarios at all. That wouldn't even fix my issue, that would just fix the code snippet I made to demonstrate my issue. What I don't agree is with the word "continuous". "Periodically" might be a better word to use. I type something, and then output is printed, and then I type something else. Maybe Go is the only language with this problem, though.
claunia commented 2026-01-31 08:18:24 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 13, 2024):

Hey, we're sorry too. We judged this bug as a case of "holding it wrong", when it should have been clear it wasn't1 .

This is definitely something we should look at. Zooming out a bit, it may be the root cause of #18080 as well--making Go not the only language impacted!--and a couple other bugs I can't name at the moment.

We've been trying to modernize the console subsystem for a while now, and that means that seven years in we're getting deeper into the behavior model; this almost certainly regressed when we rewrote the cooked read ("readline"-like) implementation back in #17455.

Thanks for your persistence, and for leading us in the right direction!

  1. As the owners of the console subsystem, we get a lot of bug reports that lie somewhere between "holding it wrong" and "Hyrum's law". This wasn't one of them, but we triaged it like it was. ↩︎

@DHowett commented on GitHub (Dec 13, 2024): Hey, we're sorry too. We judged this bug as a case of "holding it wrong", when it should have been clear it wasn't[^1]. This is definitely something we should look at. Zooming out a bit, it may be the root cause of #18080 as well--making Go not the only language impacted!--and a couple other bugs I can't name at the moment. We've been trying to modernize the console subsystem for a while now, and that means that seven years in we're getting deeper into the behavior model; this almost certainly regressed when we rewrote the cooked read ("readline"-like) implementation back in #17455. Thanks for your persistence, and for leading us in the right direction! [^1]: As the owners of the console subsystem, we get a lot of bug reports that lie somewhere between "holding it wrong" and "Hyrum's law". This wasn't one of them, but we triaged it like it was.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-CookedRead Issue-Bug Needs-Tag-Fix Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22607
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?