git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] clean: explicitly `fflush` stdout

From
Jeff King <peff@peff.net>
Date
Apr 8, 2020, 22:38 UTC
Message-ID
<20200408223821.GD3468797@coredump.intra.peff.net>
In-Reply-To
<xmqqr1wxoddc.fsf@gitster.c.googlers.com>
On Wed, Apr 08, 2020 at 02:51:11PM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> > 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.

Show 7 quoted lines
> 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
Previous: Junio C HamanoNext: Johannes Schindelin
Message 4 of 16 in “clean: explicitly `fflush` stdout”
  1. clean: explicitly `fflush` stdoutJohannes Schindelin via GitGitGadget, Apr 8, 2020
  2. Jeff KingApr 8, 2020
  3. Junio C HamanoApr 8, 2020
  4. Jeff KingApr 8, 2020
  5. Johannes SchindelinApr 10, 2020
  6. 0/2 Explicitly fflush stdout in git cleanJohannes Schindelin via GitGitGadget, Apr 10, 2020
  7. 1/2 Refactor code asking the user for input interactivelyJohannes Schindelin via GitGitGadget, Apr 10, 2020
  8. Derrick StoleeApr 10, 2020
  9. Johannes SchindelinApr 10, 2020
  10. Jeff KingApr 10, 2020
  11. Junio C HamanoApr 10, 2020
  12. 2/2 Explicitly `fflush` stdout before expecting interactive input마누엘 via GitGitGadget, Apr 10, 2020
  13. Derrick StoleeApr 10, 2020
  14. 0/2 Explicitly fflush stdout in git cleanJohannes Schindelin via GitGitGadget, Apr 10, 2020
  15. 1/2 Refactor code asking the user for input interactivelyJohannes Schindelin via GitGitGadget, Apr 10, 2020
  16. 2/2 Explicitly `fflush` stdout before expecting interactive input마누엘 via GitGitGadget, Apr 10, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.