April 16, 2024
12:55 p.m.
https://bugs.winehq.org/show_bug.cgi?id=56459 --- Comment #9 from renatopereyra(a)google.com --- > > This worked locally whenever the app does not have a console. > > 1) 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.