https://bugs.winehq.org/show_bug.cgi?id=56459
--- Comment #10 from Eric Pouech eric.pouech@gmail.com ---
Thank you for this context. I found it valuable. However, I think my wording was confusing. Sorry about that. I meant that your suggestion worked except when the Windows app allocated a console via `AllocConsole`. In that case, the output would go to the wineconsole (only). I was wondering if there was a way to send it both to the wineconsole _and_ to the Linux terminal.
If the app calls explicitely AllocConsole (or implicitely because of new process from CreateProcess), Wine implements windows' behavior which is to create a new windowed console and attach the process to it. AFAIK there's no simple way even on windows to capture current console content (the hacky way would be to send Ctrl-A, Enter keys to console window to copy console content to clipboard).
I am not sure if `< /dev/null 2>&1 | cat -` relies on expected Wine behavior that is protected by tests/review/design of some kind or if it simply leverages something that happens to work out _right now_ based on the _current_ implementation of Wine (but could change in the future).
I don't see that changing in future as it's based on the criterion to create a console attached to a unix terminal (it's done when at least one of fd 0,1,2 is a tty). We could think of "nicer" way of doing it (eg. env variable not to bind to unix console when set, or small shell script to wrap that up...) something like this would do: ``` #!/bin/sh
if [ -t 0 ]; then exec 0< /dev/null ; fi if [ -t 1 ]; then exec 1> /dev/null ; fi if [ -t 2 ]; then exec 2> /dev/null ; fi
exec "$@" ```
This does not match what I observed with the latest Wine 9.5 release using `< /dev/null 2>&1 | cat -`. I found stdout to print first as a whole block, even when the buffer size had not been exceeded. The command line I used was `wine debug_string_test.exe -count 4000 < /dev/null 2>&1 | cat -`, based on the test app I attached to this bug.
the fix for unbuffering stderr will land in Wine 9.7
moreover, what you seem to want is line buffering (ie ensuring a line up to \n is printed at once); this is defined in CRT with _IOLBF flag to setvbuf. Sadly, native Windows CRT implements _IOLBF as _IOFBF, so it won't be of any help here.
My limited testing in Windows suggests this is applicable when output is routed to a file but not when output is printed to a console allocated by `AllocConsole`. The Windows console appears to be line-buffered. The command line I used was `debug_string_test.exe -count 2 -console_before_print` and I observed stderr interleaved with stdout.
console is unbuffered
to check your claim this you need to intertwin write:s to stdout and stderr.
for (int i = 0; i < 2000; i++) { fputc('1', stdout); fputc('2', stderr); if (!(i % 37)) { fputc('\n', stdout); fputc('\n', stderr); } } and you should get: - lines of "12" character pairs when not buffered - pair of a line of 1:s followed by a line of 2:s when line buffered - block (4096 chars) of lines of 1 followed by block of lines of 2 when buffered