All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>,
	git@vger.kernel.org, 마누엘 <nalla@hamal.uberspace.de>
Subject: Re: [PATCH] clean: explicitly `fflush` stdout
Date: Fri, 10 Apr 2020 16:03:26 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2004101602330.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20200408201454.GB2270445@coredump.intra.peff.net>

Hi Peff,

On Wed, 8 Apr 2020, Jeff King wrote:

> On Wed, Apr 08, 2020 at 07:33:00PM +0000, Johannes Schindelin via GitGitGadget wrote:
>
> > From: =?UTF-8?q?=EB=A7=88=EB=88=84=EC=97=98?= <nalla@hamal.uberspace.de>
> >
> > For performance reasons `stdout` is buffered by default. That leads to
> > problems if after printing to `stdout` a read on `stdin` is performed.
>
> This first paragraph left me scratching my head. It's only a problem for
> interactive uses, right? Would:
>
>   This can lead to problems for interactive commands which write a
>   prompt to `stdout` and then read user input on `stdin`. If the prompt
>   is left in the buffer, the user will not realize the program is
>   waiting for their input.
>
> make sense?

Thank you, yes, that makes sense.

Based on another suggestion of yours, I did refactor the code a bit more
and already sent out the result as v2.

Thank you,
Dscho

>
> > For that reason interactive commands like `git clean -i` do not function
> > properly anymore if the `stdout` is not flushed by `fflush(stdout)` before
> > trying to read from `stdin`.
>
> I'm not sure I understand this "anymore". Did the buffering change at
> some point, introducing a regression?
>
> > So let's precede all reads on `stdin` in `git clean -i` by flushing
> > `stdout`.
>
> This (and the patch) make sense to me. It might be worth factoring out a
> "read input from user" function and putting the flush there, but with
> only three affected call sites, I'm OK with it either way.
>
> >     This is yet another patch that was funneled through a Git for Windows
> >     PR. It has served us well for almost five years now, and it is beyond
> >     time that it find its final home in core Git.
>
> 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).
>
> -Peff
>

  parent reply	other threads:[~2020-04-10 14:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-08 19:33 [PATCH] clean: explicitly `fflush` stdout Johannes Schindelin via GitGitGadget
2020-04-08 20:14 ` Jeff King
2020-04-08 21:51   ` Junio C Hamano
2020-04-08 22:38     ` Jeff King
2020-04-10 14:03   ` Johannes Schindelin [this message]
2020-04-10 11:27 ` [PATCH v2 0/2] Explicitly fflush stdout in git clean Johannes Schindelin via GitGitGadget
2020-04-10 11:27   ` [PATCH v2 1/2] Refactor code asking the user for input interactively Johannes Schindelin via GitGitGadget
2020-04-10 12:27     ` Derrick Stolee
2020-04-10 14:01       ` Johannes Schindelin
2020-04-10 15:07     ` Jeff King
2020-04-10 17:44     ` Junio C Hamano
2020-04-10 11:27   ` [PATCH v2 2/2] Explicitly `fflush` stdout before expecting interactive input 마누엘 via GitGitGadget
2020-04-10 12:28     ` Derrick Stolee
2020-04-10 18:16   ` [PATCH v3 0/2] Explicitly fflush stdout in git clean Johannes Schindelin via GitGitGadget
2020-04-10 18:16     ` [PATCH v3 1/2] Refactor code asking the user for input interactively Johannes Schindelin via GitGitGadget
2020-04-10 18:16     ` [PATCH v3 2/2] Explicitly `fflush` stdout before expecting interactive input 마누엘 via GitGitGadget

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2004101602330.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=nalla@hamal.uberspace.de \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.