Re: Incomplete output from "cvs annotate"

[Kim F. Storm]

Andreas Schwab <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> 
> > In latest CVS emacs on GNU/Linux (redhat9.0), I noticed that the following
> > sequence: 
> >
> >         C-h C-n         (open NEWS)
> >         C-x v g         (annotate it)
> >
> > produces a very incomplete annotate buffer (approx 2/3 of the output is 
> > missing).
> >
> [...]
> > So the big questions are -- and this is where I'm stuck:
> >
> >         What is so special with cvs annotate and call-process?
> 
> Nothing, it can happen with any cvs command over ssh (you can get partial
> checkins, for example).
> 
> >         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 "$@"
> 
> Andreas.


Thanks for the pointer.

Knowing the cause, there is a simple work-arond in emacs, as the
following call-process usage avoids having emacs tying stderr into
stdout; instead, it redirects stderr to /dev/null:

  (call-process "/usr/bin/cvs" nil '(t nil) nil "annotate" "vc.el")

I suppose the cvs backend could use this to avoid the problems.

Actually, I think merging stdout and stderr when calling cvs (or some
other vc tool) is generally a bad thing, as you risk ending up with
error messages in checked out files, so perhaps cvs (and vc in
general) should do this sort of thing always.

I haven't checked pcl-cvs, but I suppose it could use a similar
remedy for the problems it has with cvs+ssh?!

-- 
Kim F. Storm <address@hidden> http://www.cua.dk