Looking at the source, the cause is simply that fflush is currently not implemented: https://github.com/kripken/emscripten/blob/incoming/src/library.js#L2420

Implemented this in the above pull request. One limitation of our fflush is that it will always cause a newline to be printed.

Ran into the same issue, very confusing until I realized fflush wasn't working.

Ouch, the situation is a bit trickier than I thought. I had to revert the fflush implementation for now, since it breaks printing to std::cerr completely. See this commit b759913

The main problem is that since printing to a web console is line-based, we cannot fflush without introducing a newline. std::cerr is unbuffered, and it flushes between every << operation, so implementing fflush to introduce a newline caused std::cerr to print its components each on their own lines, so that's not very good.

The old behavior where fflush was completely ignored is troublesome because there are often questions/bug reports coming in with "printf is not working", when the user forgets to add a newline \n to the end of the sequence that is printed, or they are explicitly calling fflush and are observing that it does not perform any function.

I'm not sure what's a good way to proceed here. One might be to attempt to remove the use of fflush in libc++, but it's a bit uncertain if that might affect some other uses, like syncing/flushing to file outputs, so not sure if we want to do that. Another might be to enable fflush only on a specific linking flag -s ENABLE_FFLUSH=1. That might at least give users who don't care about std::cerr something to work on. Perhaps a third way would be to always flush when 1) we exit main, and 2) when we exit a single iteration of the main loop. That still has the issue that fflush cannot be supported and must be a no-op.

If anyone has better suggestions, let me know.

I thought we already flush when we exit main? (I think when we shut down the FS) When I tested that now it worked using printf("text"); and nothing more.

Flushing on each main loop iteration is interesting. I'm sure it would help some things, but also break others. Not sure what is best.

We flush when we exit main only when user did not call emscripten_set_main_loop and the user did not call -s NO_EXIT_RUNTIME=1, so practically, we don't flush when we exit main. I don't know what would be the best behavior here, it doesn't feel like we have a single way of "supporting everything" without breaking some other case.

I see, ok. Yes, we can't fix this 100%. I don't have any other ideas.

We could do a "#define printf emscripten_internal_printf" in "emscripten.h" before the "stdio.h".

I think it could also work for the STL (cout ...).

In "emscripten_internal_printf()" we will know the state of the buffer. It is may be "fread/fwrite" to trap...

It is based on my understanding that the standart functions are replaced at link time.

May be I'm wrong...

dlmalloc do that for malloc().

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.

It looks to me like the solution to this would be to move the endline handling to the javascript side. So that '\n' is sent normal to javascript. Also note I've put some effort into implementing xterm at https://github.com/xloem/emterm which provides better for flushes of partial lines.

@kripken Also hit the same issue while using busybox for an in-browser terminal application (https://busytex.github.io).

In particular, busybox clear doesn't print a new line: https://github.com/brgl/busybox/blob/master/console-tools/clear.c

This is aggravated by the fact that I don't let the emscripten module clean up and exit, and instead I reset the module's memory myself.

@sbc100 Is there a way to manually flush the streams from JavaScript side?