[Top][All Lists]

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

Re: Lost process output in pipe between Emacs and CVS

From: Derek Robert Price
Subject: Re: Lost process output in pipe between Emacs and CVS
Date: Fri, 09 Aug 2002 08:39:16 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606

Stefan Monnier wrote:

The problem is that people use cvs 2>&1 with CVS_RSH set to ssh, and
expect it to work, and think it is a CVS bug when it fails.  Educated
users don't have a problem.
Perhaps a quick fix then is to detect that stdio has been set to
nonblocking and output an error message?

The circumstances under which the problem appears are sufficiently
particular that there are tens of quick fixes available.  The question
is how to fix it for real such that neither SSH nor CVS nor PCL-CVS
(in Emacs) need to work around the problem at a functionality or
performance cost.

How do non-glibc systems deal with it ? (I've only seen the
problem reported on glibc systems until now)
It seems legitimate to use stdio on stderr without having to worry about
some application that you have forked and that thus shared your stderr,
so I think the problem is that glibc's stdio does not correctly handle
the case where the file is in non-blocking mode.


I agree, I would prefer to see this fixed in stdio, but Paul Eggert objected to this in an offshoot to this thread on at least the bug-cvs@gnu.org mail list based on the fact that it conflicted with the POSIX definition: <http://www.mail-archive.com/bug-cvs%40gnu.org/msg04461.html>.

Paul suggests an extension to stdio to avoid conflicts with the POSIX spec. Is this reasonable?



Email: derek@ximbiot.com

Get CVS support at http://ximbiot.com
I know of no safe depository of the ultimate powers of the society but the
people themselves, and if we think them not enlightened enough to exercise that
control with a wholesome discretion, the remedy is not to take it from them,
but to inform their discretion.

- Thomas Jefferson, 1820.

reply via email to

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