This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Unbuffer stdout and stderr on windows
- From: Christopher Faylor <cgf-use-the-mailinglist-please at sourceware dot org>
- To: gdb-patches at sourceware dot org, Yao Qi <yao at codesourcery dot com>, Eli Zaretskii <eliz at gnu dot org>
- Date: Mon, 29 Jul 2013 15:25:59 -0400
- Subject: Re: [PATCH] Unbuffer stdout and stderr on windows
- References: <1374462417-7961-1-git-send-email-yao at codesourcery dot com> <838v0yy556 dot fsf at gnu dot org> <51EE23F8 dot 1070905 at codesourcery dot com> <83wqohw4ee dot fsf at gnu dot org>
On Tue, Jul 23, 2013 at 08:51:53PM +0300, Eli Zaretskii wrote:
>> Date: Tue, 23 Jul 2013 14:34:32 +0800
>> From: Yao Qi <yao@codesourcery.com>
>> CC: <gdb-patches@sourceware.org>
>>
>> On 07/22/2013 11:40 PM, Eli Zaretskii wrote:
>> > This is wrong, stdout should be line-buffered by default.
>> >
>>
>> stdout is line-buffered if it can be detected to connect to an
>> interactive device, otherwise it is fully buffered. Cygwin emulates pty
>> with pipes, and native win32 apps blindly assume all pipes are
>> non-interactive.
>
>Sorry, I was unclear: I meant that stdout should be line-buffered, not
>unbuffered, when it is connected to a console (which is the default).
>I was under the impression that you were changing stdout to be
>unbuffered even in that default case, i.e. even when stdout is
>connected to a console. If that's not so, i.e. if you were changing
>the buffering only when stdout is not connected to a console, I
>apologize for my misunderstanding.
>
>> > Also, this punishes batch mode with stdout redirected to a file: its
>> > stdout buffering (and perhaps also that of stderr, although that's
>> > less important) will now always be line-buffered, i.e. less efficient.
>>
>> Yeah, this patch hurts the performance, but gets the outputs in the
>> correct order, so that testsuite can be run to get a reasonable test result.
>
>I don't think it's right to penalize users for the benefit of the test
>suite.
>
>> > Is it possible to detect the "Cygwin ssh session", whatever that
>> > means, and only do this then? I don't think it's right to change
>>
>> Unfortunately, I am unable to find a heuristics to tell "GDB is in
>> cygwin session". There are some differences on env variables between
>> cygwin and Windows cmd.exe console, but I am afraid that they are not
>> reliable.
>
>Then how about introducing a special option which will cause the
>buffering to be what you want? The test suite could use that option,
>and the other users will not suffer any penalty.
>
>> > behavior of a native w32 GDB just because it misbehaves when mixed
>>
>> This patch is to change the buffered output to unbuffered, so the
>> behaviour of GDB is not changed, IMO.
>
>Of course it's changed: buffering is user-visible behavior.
>
>> In the last resort, we may add an option "--cygwin-tty"
>
>I think this is the best alternative.
>
>> which I don't really like.
>
>Why not?
Note that this is only a problem for non-Cygwin versions of gdb. It
sounds like someone is using mingw-built versions of gdb in a cygwin
pty session. This obviously wouldn't be something that Cygwin itself
would need.
How about a "--buffer-output" option instead, which defaults to true?
cgf