Thread overview
Windows Msys terminal not flushing on newlines
Mar 27, 2022
Anonymouse
Mar 27, 2022
Adam D Ruppe
Mar 27, 2022
kdevel
Mar 27, 2022
Anonymouse
March 27, 2022

I installed Git for Windows which comes with the Msys terminal, and I noticed writeln lines aren't being flushed on linebreaks. I had this a long time ago and thought I fixed it with the following, but I guess I never confirmed that it actually worked. I'm not sure where I copied it from, a TWiD perhaps?

import std.stdio : stdout;
import core.stdc.stdio : _IOLBF;
stdout.setvbuf(4096, _IOLBF);  // arbitrary number

Is this not the right way to go about things? At least for Msys it seemingly does nothing.

March 27, 2022
On Sunday, 27 March 2022 at 17:46:54 UTC, Anonymouse wrote:
> I installed Git for Windows which comes with the Msys terminal, and I noticed writeln lines aren't being flushed on linebreaks

If the C library thinks it is talking to a pipe, it will switch to block buffering instead of line buffering. It must just think msys is a pipe (since it probably is under the hood).

Normally the IOLBF thing does help there - that means line buffering - but my recommentation is to explicitly call `stdout.flush()` any time it is important in your code. Then you aren't depending on the relatively hidden config value.
March 27, 2022
Don't know if this is OT here.

On Sunday, 27 March 2022 at 18:09:30 UTC, Adam D Ruppe wrote:
> If the C library thinks it is talking to a pipe, it will switch to block buffering instead of line buffering. It must just think msys is a pipe (since it probably is under the hood).

while compiling a project with make -j6 I see this:

[...]
decimal/decimal.d(13080): decimal/decimal.d(13080): Deprecation: Deprecation: UUssagea goef  otfh et h`e `bodbyody` k`e ykweoyrwdo rids  idse pdreepcraetceadt.e dU.s eU s`e `dodo` i`n sitnesatde.a
d.
decimal/decimal.d(13217): decimal/decimal.d(13217): Deprecation: Deprecation: UUssaaggee  ooff  tthhee  ``bbooddyy``  kkeeyywwoorrdd  iiss  ddeepprreeccaatteedd..  UUssee  ``ddoo``  iinnsstteeaadd..

decimal/decimal.d(13239): Deprecation: decimal/decimal.d(13239): UDeprecation: sageU soafg et hoef  `the b`odybo`d ykey`w okredy wiosr dd eipsr edceaptreedc.a tUesde.  `Use d`o`d oins`t eiands.t
ead.
decimal/decimal.d(13327): decimal/decimal.d(13327): Deprecation: Deprecation: UUssaaggee  ooff  tthhee  ``bbooddyy``  kkeeyywwoorrdd  iiss  ddeepprreeccaatteedd..  UUssee  ``ddoo``  iinnsstteeaadd..

The write calls are mostly unbuffered as strace reveals:

29680 write(2, "\33[1m", 4)             = 4
29680 write(2, "decimal/decimal.d(471): ", 24) = 24
29680 write(2, "\33[1;36m", 7)          = 7
29680 write(2, "Deprecation: ", 13)     = 13
29680 write(2, "\33[m", 3)              = 3
29680 write(2, "U", 1)                  = 1
29680 write(2, "s", 1)                  = 1
29680 write(2, "a", 1)                  = 1
29680 write(2, "g", 1)                  = 1
29680 write(2, "e", 1)                  = 1
29680 write(2, " ", 1)                  = 1
29680 write(2, "o", 1)                  = 1
29680 write(2, "f", 1)                  = 1
29680 write(2, " ", 1)                  = 1
29680 write(2, "t", 1)                  = 1
29680 write(2, "h", 1)                  = 1
29680 write(2, "e", 1)                  = 1
29680 write(2, " ", 1)                  = 1

> Normally the IOLBF thing does help there - that means line buffering - but my recommentation is to explicitly call `stdout.flush()` any time it is important in your code. Then you aren't depending on the relatively hidden config value.

Shall I file an issue for this?
March 27, 2022

On Sunday, 27 March 2022 at 18:09:30 UTC, Adam D Ruppe wrote:

>

Normally the IOLBF thing does help there - that means line buffering - but my recommentation is to explicitly call stdout.flush() any time it is important in your code. Then you aren't depending on the relatively hidden config value.

All right, thanks.