bug-cvs
[Top][All Lists]
Advanced

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

Re: Lost process output in pipe between Emacs and CVS


From: Ian Lance Taylor
Subject: Re: Lost process output in pipe between Emacs and CVS
Date: 24 Jul 2002 20:15:43 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

kevin wang <kjw@rightsock.com> writes:

> > The problem is that in a standard configuration:
> > 
> >            --stderr->     -------------stderr------------>
> >           /          \   /                     /          \
> > CVS Server            ssh            CVS client            tty
> >           \          /   \          /          \          /
> >            --stdout->     --stdout->            --stdout->
> > 
> > Note that since CVS didn't access the stderr of its child process, ssh, 
> > the child process gets a clone of the parent process' stderr descriptor 
> > and ssh and the CVS client end up sharing the tty's standard error.
> > 
> > Now, when the user redirects stderr to stdout, say, to redirect the 
> > output to a file (e.g. CVS_RSH=ssh cvs diff >tmp.diff 2>&1), you get the 
> > following configuration:
> 
> This may sound silly, but as a temporary workaround, can't you:
> 
> CVS_RSH=ssh cvs diff >tmp.diff 2>tmp.diff 

Sure (in append mode), or, even easier, don't use 2>&1 at all.  Or do
what I do, and set CVS_RSH to a shell script which invokes ssh with
2>/dev/null.  That always works--if ssh fails you can just run it by
hand to see the error message.

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.

Ian



reply via email to

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