[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 <derek@ximbiot.com> 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.
- Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Derek Robert Price, 2004/09/02
- Re: CVS update [cvs1-11-x-branch]: /ccvs/src/,
Paul Eggert <=
- Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Simon Josefsson, 2004/09/02
- Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Derek Robert Price, 2004/09/02
- Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Paul Eggert, 2004/09/02
- Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Derek Robert Price, 2004/09/03
- Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Paul Eggert, 2004/09/03
- Re: [Bug-gnulib] Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Bruno Haible, 2004/09/04
- Re: [Bug-gnulib] Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Derek Robert Price, 2004/09/04
- Re: [Bug-gnulib] Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Bruno Haible, 2004/09/06
- Re: [Bug-gnulib] Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Derek Robert Price, 2004/09/07
- Re: [Bug-gnulib] Re: CVS update [cvs1-11-x-branch]: /ccvs/src/, Bruno Haible, 2004/09/04