bug-cvs
[Top][All Lists]
Advanced

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

Re: CVS update [cvs1-11-x-branch]: /ccvs/src/


From: Paul Eggert
Subject: Re: CVS update [cvs1-11-x-branch]: /ccvs/src/
Date: Thu, 02 Sep 2004 01:18:41 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Derek Robert Price <address@hidden> writes:

> The alternative would seem to be a fix at the OS level to prevent
> stdout & stderr from being set nonblock,

That sounds unlikely.  Among other things, I don't think POSIX
allows it.

I recall proposing a less-intrusive solution; see
<http://lists.gnu.org/archive/html/bug-cvs/2002-08/msg00032.html>.
You demurred because it involves a separate process to copy stderr and
you were worried about the inefficiencies involved.  Can you quantify
these inefficiencies?  Perhaps they're not worth worrying about, in
practice.  If so, the extra-process solution may be the way to go,
despite its minor inefficiencies.

I am now switching to use a workaround that approximates that
solution, by pointing CVS_RSH to the following shell script, which I
call "ssh4cvs".

   #! /bin/sh

   # Arrange so that ssh's stderr is never stdout,
   # by interposing a "cat" process between ssh's
   # stderr and our stderr.  Why bother?  Because
   # ssh puts stderr into nonblocking mode, and
   # CVS (which uses stdio for stdout) gets confused
   # if stdout and stderr are the same file.
   # See:
   # http://lists.gnu.org/archive/html/bug-cvs/2002-08/msg00032.html

   exec 3>&1

   exit `((ssh "$@" 2>&1 >&3; echo $? >&4) | cat -u >&2) 4>&1`

This solution is less efficient than the one I proposed, but it
doesn't involve changing CVS and it fixed the bug for me in the one or
two examples I tried.  I don't notice the performance hit in practice,
not that I am measuring it.

> SSH's behavior may very well be "rude" but, even if they fix the
> problem on their end, there is nothing stopping some other program
> (PuTTY, commercial SSH clients, whatever) from doing the same thing.

If SSH is the only program doing it, perhaps they could be convinced
that it's a bug.  However, it'd be nice to fix this for CVS even if
SSH changes in behavior, as many people will use old SSH versions.

> Perhaps having a substitute for the stdio routines is still the best
> preventative measure for this sort of problem.

But this would require rewriting/auditing every part of CVS that can
write to the affected descriptors, no?  A thankless and error/prone
job.  No wonder nobody wants to do it.  It'd likely introduce bugs.




reply via email to

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