Bug 20215 – redirected console app looks hang w/o .flush

----------------------- import std; void main() { for (int k=1; k<10_000; ++k) // non ascii doesn't matter, just for longer string writeln( "hello world and привет and salut"); "done.".writeln; // without it - SUBJ //stdout.flush; // without it (this app finished here) OK readln; } ----------------------- NB: REDIRECTED output to file prog.exe > file.data output at the end looks like this: hello world and привет and salut hello world and привет and salut hello world and привет and salut hello world and I don't see that app is finished - no line "done." app looks halted at some middle point. lab: one console runs app. other console (FAR manager = like Night Commander) view/F3 at file.data why so strange? cause prints to real console is 100x slower then to file. and viewing file/log u can stop at any interested line while output is continue. so look at such output my thoughts is: - maybe something wrong was compiled? - maybe GC freeze for minutes? what?! - maybe try same with C#?.. hmm.. is working here!.. what again wrong with D? - maybe to use printf instead writeln? possible solution (iirc Stroustrup said it at 2nd edition C++ book in 90s for cin/cout) when u try read data from input, flush output first. when program prints "input numbers: " and try read nums but string is buffered and no hints (on screen) what should user think? so readln should flush output first or better is // automatically flush but can be manually disabled for -1 syscall readln( term ='...', shouldFlush =true) // shouldFlush=false - means same. u will forget to flush current workaround - manually flush better solution - flush automatically for stupid and forgetful users like me

UPD I checked printf/cout behavior: D/printf: same result - looks freeze VС++/printf: same result VC++/cout/cin: flushes ok. maybe readln(...) can be same for repeating C/printf/getchar but can be added readlnWithFlush(..) user will search readXXX, nobody will search flushAndReadXXX readlnWithFlush will stay near readln then user will think: "readlnWithFlush flushes and readln dont flush. ok then.." u comfort with C/system-style printf/writeln when u remember that need to flush before input. me comfort with higher level C#/C++/cout where readln flushes output automatically and I dont remember that I should flush first. and I mean not flush every output that expensive, I mean "flush output before input when output is not empty or in case u cannot say that - flush automatically if user ask dont do that"

>app looks halted at some middle point It waits for input in readln, type text and press enter, the process will continue execution. Buffering for file output is by design for better performance, like for any file. You can adjust flushing settings with setvbuf method.