From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: Incomplete output from "cvs annotate" Date: Mon, 19 Jan 2004 17:34:10 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1074530313 728 80.91.224.253 (19 Jan 2004 16:38:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 19 Jan 2004 16:38:33 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Jan 19 17:38:25 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AicPw-0007jM-00 for ; Mon, 19 Jan 2004 17:38:24 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AicPw-0003LT-00 for ; Mon, 19 Jan 2004 17:38:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AicP3-0004K3-EG for emacs-devel@quimby.gnus.org; Mon, 19 Jan 2004 11:37:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AicOF-00044h-KM for emacs-devel@gnu.org; Mon, 19 Jan 2004 11:36:39 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AicNg-0003mC-A2 for emacs-devel@gnu.org; Mon, 19 Jan 2004 11:36:35 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1AicNf-0003k0-Sl for emacs-devel@gnu.org; Mon, 19 Jan 2004 11:36:03 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by mx20.gnu.org with esmtp (Exim 4.24) id 1AicMC-0000mc-89 for emacs-devel@gnu.org; Mon, 19 Jan 2004 11:34:32 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AicMA-00037O-00 for ; Mon, 19 Jan 2004 17:34:30 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AicM8-00037G-00 for ; Mon, 19 Jan 2004 17:34:28 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AicM8-0008SM-00 for ; Mon, 19 Jan 2004 17:34:28 +0100 Original-Lines: 43 Original-X-Complaints-To: usenet@sea.gmane.org User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:wDGluVau4dRoCbmsViTnCHgfZfw= X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:19273 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19273 Andreas Schwab writes: > Simon Josefsson writes: > >> Andreas Schwab 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 . 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.