https://bugs.winehq.org/show_bug.cgi?id=56459
--- Comment #9 from renatopereyra@google.com ---
This worked locally whenever the app does not have a console.
- Is there a way to get the output to (also) print to the Linux side even
when there is a console?
the command above ensures that:
- wine is started without a (unix) console
- but first program has its I/O stream bound to the unix fd (here 1,2 of wine program are printed to unix 1)
- if first program starts another GUI program, the Windows default behavior is that the streams are *NOT* inherited by second (and subsequent program)
- under certain conditions, Wine starts first a dedicated program (start.exe); if you're in that case, your launched app will not be able to print
- you can test if its the case by ensuring that you use the full path to your application on command line
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.
2 It seems a bit unsafe to rely on this long-term. Is there or could there be some kind of test in Wine that protects this kind of use/behavior?
what do you mean?
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).
lines from stderr are printed, until stdout buffer is full (its content is printed in bulk), then stderr keeps on printing and so...
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.
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.