Hi Hannes, On Wed, 15 Feb 2017, Johannes Sixt wrote: > Am 15.02.2017 um 13:32 schrieb Johannes Schindelin: > > On Tue, 14 Feb 2017, Johannes Sixt wrote: > > > Am 14.02.2017 um 15:47 schrieb Johannes Schindelin: > > > > On Mon, 13 Feb 2017, Junio C Hamano wrote: > > > > > Johannes Schindelin <johannes.schindelin@xxxxxx> writes: > > > > > > What we forgot was to mark stderr as unbuffered again. > > > > > > I do not see how the earlier patch turned stderr from unbuffered to > > > buffered, as it did not add or remove any setvbuf() call. Can you > > > explain? > > > > [ motivation and history of js/mingw-isatty snipped ] > > > > So instead of "bending" the target HANDLE of the existing > > stdout/stderr (which would *naturally* have kept the > > buffered/unbuffered nature as-is), we now redirect with correct API > > calls. > > Your statement implies that at the time when winansi_init() begins, > stdio is already initialized and the buffered/unbuffered state has been > set for stderr. I would think that this is true. > > Then we swap out the file handle underlying stderr in swap_osfhnd() > using dup2(). Why would that change the buffered state of stdio? The file handle we swap in for stderr points to the pipe that a freshly-started thread consumes for parsing the ANSI color sequences. This handle is used both for stdout and stderr. The dup2() call then implicitly reopens stderr, with the default buffering. > > And the patch I provided at the bottom of this mail thread reinstates > > the unbuffered nature of stderr now that it gets reopened. > > > > Hopefully that makes it clear why the setvbuf() call is required now, > > but was previously unnecessary? > > Unfortunately, no. I do not see how dup2() causes a change in stdio state. I > must be missing something (and that may be a basic misunderstanding of how > stdio is initialized). It appears that dup2()ing fd 2 resets that stdio state. Ciao, Dscho