The problem is that people use cvs 21 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.
Perhaps a quick fix then is to detect that stdio has been set to
nonblocking and output an error message?
The
Stefan Monnier wrote:
The problem is that people use cvs 21 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.
Perhaps a quick fix then is to detect that stdio has been set to
nonblocking and output an error
The problem is that people use cvs 21 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.
Does educated users mean users who know they have to avoid 21
when using CVS_RSH=ssh? If so, I would say that they
Richard Stallman [EMAIL PROTECTED] writes:
The problem is that people use cvs 21 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.
Does educated users mean users who know they have to avoid 21
when
From Ian Lance Taylor
I don't see a right answer here. Maybe CVS should include a script
which calls ssh piping stderr to cat, and tell people to use that
instead of using ssh.
If you're looking for 'cat' to do infinite buffering, i.e. it will
keep adsorbing input even while the output is
From Richard Stallman
If a buffer flush fails with EAGAIN during
printf, what should happen?
printf should retry, perhaps after a short sleep, and thus more or
less emulate the behavior with an ordinary blocking descriptor.
If you want to emulate blocking behaviour, then why not
kevin wang wrote:
From Ian Lance Taylor
I don't see a right answer here. Maybe CVS should include a script
which calls ssh piping stderr to cat, and tell people to use that
instead of using ssh.
If you're looking for 'cat' to do infinite buffering, i.e. it will
keep adsorbing input
From Derek Robert Price
The problem is that in a standard configuration:
--stderr- -stderr
/ \ / / \
CVS ServersshCVS clienttty
\ / \
kevin wang wrote:
This may sound silly, but as a temporary workaround, can't you:
CVS_RSH=ssh cvs diff tmp.diff 2tmp.diff
that ought to open the file twice as separate file descriptors.
The downside is that I/O is now unsynchronized, and lines may be inserted
in the middle of other lines, but
kevin wang [EMAIL PROTECTED] writes:
The problem is that in a standard configuration:
--stderr- -stderr
/ \ / / \
CVS ServersshCVS clienttty
\
kevin wang [EMAIL PROTECTED] writes:
From Richard Stallman
If a buffer flush fails with EAGAIN during
printf, what should happen?
printf should retry, perhaps after a short sleep, and thus more or
less emulate the behavior with an ordinary blocking descriptor.
If you
This is a different case. CVS is invoking ssh in a child process in a
way which causes them to share file descriptor 2. ssh is then
unblocking file descriptor 2 in a way which CVS does not expect. This
type of problem can only happen with programs which invoke ssh.
In that
CVS uses stdio, and stdio doesn't work very well with non-blocking
file descriptors. CVS can detect the error easily enough, but at that
point stdio has already thrown away the buffer full of data, and CVS
hasn't recorded it anywhere. While in principle CVS could switch to
Thanks Ian for your help. I'm rather glad to hear that it can be
reproduced outside of Emacs since I can now lay the blame on someone
else (people used to say it doesn't work in PCL-CVS but it works with
VC so it must be a problem with PCL-CVS ;-).
CVS uses stdio, and stdio doesn't work
Stefan Monnier [EMAIL PROTECTED] writes:
Over the last few years, I've had several times people complain about
PCL-CVS' diff output being incorrect (with parts missing).
Now my direct `read' calls from GDB make me believe that maybe the
problem is not in Emacs, but in CVS instead (I use
But the fact that `cvs diff src/minibuf.c |(sleep 120; wc)' works
correctly make me think that maybe it is a bug in Emacs.
It might be a bug in Emacs that fails to read everything coming thru
the pipe when the subprocess terminates. Can you see if it is that?
Did you already check and
Stefan Monnier [EMAIL PROTECTED] writes:
Another notable thing is that this whole problem disappears if I
change PCL-CVS to use a pty rather than a pipe for the process' output.
(I noticed it because the problem doesn't appear with VC which is
not careful to use a pipe).
Now my direct
Over the last few years, I've had several times people complain about
PCL-CVS' diff output being incorrect (with parts missing).
Since the FSF' kerberos server was down, I had to switch to SSH
access and finally for the first time I've experienced this lossage
first hand.
Assuming that the
18 matches
Mail list logo
