Re: CVS update [cvs1-11-x-branch]: /ccvs/src/
Paul Eggert <[email protected]> Thu, 02 Sep 2004 01:18:41 -0700
| Newsgroups | gmane.comp.lib.gnulib.bugs,gmane.comp.version-control.cvs.bugs |
|---|---|
| Message-ID | <[email protected]> |
Derek Robert Price <[email protected]> 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.