On Wed, Apr 08, 2020 at 02:51:11PM -0700, Junio C Hamano wrote: > > Agreed. I guess it didn't affect people on other platforms much because > > stdout to a terminal is generally line-buffered on POSIX systems. But > > it's better not to rely on that, plus it could create confusion if > > somebody tried to manipulate the interactive operation through a pipe > > (e.g., driving it from a GUI or something). > > Hmph, I thought it was more common to do prompts etc. on the > standard error stream, which tends to make the buffering of the > output less of a problem, but apparently these prompts are given to > the standard output. The prompts in git-add--interactive.perl go to stdout, as do the ones for "am --interactive". I think that's reasonable, if you think of it as the main output of the program. At one point the "am" ones actually went to /dev/tty, but IMHO that's a mistake. In 99% of cases it behaves the same as looking at stdin/stdout (because they're connected to the terminal anyway), and in the other 1% it's just as likely to be the wrong thing as the right. Plus it makes testing much harder. > I am also OK to sprinkle fflush(stdout) but in > the longer term, it would probably be a good idea to introduce a > helper to "prompt then grab input" or "read user input" (if the > former, we'd be able to bring consistency into "which between the > standard output or the standard error does a prompt come?", and if > the latter we'd do fflush(NULL) before reading), especially if there > are many git subcommands that go interactive. Agreed. There is git_prompt(), but that does the tty thing, which I think we'd want to avoid in most cases. It's used by the credential code, which really does want to use a terminal to do things like turn off character echoing. Plus it's not the main function of the program, but rather a side effect (so we have to avoid disrupting the main stdin/stdout). -Peff
