Re: Incomplete output from "cvs annotate"

[Simon Josefsson <jas@extundo.com>]

Andreas Schwab <schwab@suse.de> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Andreas Schwab <schwab@suse.de> writes:
>>
>>>>         Why is the pipe opened by call-process -- and which cvs (as
>>>>         well as my wrapper around cvs) writes to -- in non-blocking
>>>>         state?
>>>
>>> See <http://mail.gnu.org/archive/html/bug-cvs/2002-07/msg00423.html>.  The
>>> problem is that ssh makes stderr non-blocking and Emacs connects stdout
>>> and stderr together, so that stdout becomes non-blocking as well.
>>> Workaround is to separate stdout and stderr again, eg. by using this
>>> script as CVS_RSH:
>>>
>>> #!/bin/bash
>>> exec 2> >(exec cat >&2 2>/dev/null)
>>> exec ssh "$@"
>>
>> This workaround isn't a good solution.  Why do Emacs connect stdout
>> and stderr together?
>
> You can either redirect stderr to a file, discard it completely, or
> capture it in the same buffer as stdout.  In the latter case Emacs just
> uses the same fd for both, which corresponds to 2>&1 in the shell.
>
>> IMHO, it shouldn't.  If the data need to be collapsed into the same
>> buffer, it should happen inside Emacs, not by cloning the fd.  So using
>> a BUFFER cons cell in VC for call-process isn't a solution, using just
>> one BUFFER should work.
>
> This is what VC is doing.

So what's the problem?  If VC is using a cons cell, I'd assume the
same fd isn't used for both stdout and stderr, but people's experience
seem to indicate the bug is still around.  Was VC changed recently,
perhaps?  I haven't seen my C-x v u problem for a while, although I
have not used it all that often lately.

If VC is using a cons cell, and that leads to using different fd's for
stdout and stderr, I believe the problem above isn't the same problem
as what we are seeing now.