[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Incomplete output from "cvs annotate"

From: Andreas Schwab
Subject: Re: Incomplete output from "cvs annotate"
Date: Mon, 19 Jan 2004 16:45:36 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux)

Simon Josefsson <address@hidden> writes:

> Andreas Schwab <address@hidden> 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.


Andreas Schwab, SuSE Labs, address@hidden
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

reply via email to

[Prev in Thread] Current Thread [Next in Thread]