Jeff Bailey <[EMAIL PROTECTED]> writes:
> On Tue, Feb 20, 2001 at 01:11:15PM +0100, Niels Mvller wrote:
>
> > My current understanding of the problem is that lsh (and lshg) sets
> > its stdio file descriptors into non-blocking mode, and that cvs is
> > confused by that.
>
> ls uses code to determine if it's talking to a terminal or not. Would a
> trick like that work for lsh (use CVS mdoe if not talking to a terminal)
Perhaps, but I'd like to understand what is happening first. And it
might be better to simply enable the workaround all the time.
What --cvs-workaround does is this: It creates a pipe, and forks a
separate process to copy data from the pipe to stdout, and similarly
for stderr and stdin (but in the stdin case, the copying is obviously
from stdin to the pipe). That way, the stdio fd:s can be left
untouched, and lsh only sets its ends of the pipes into non-blocking
mode.
The only lossage with this I can think of is that data may be lost if
lsh dies while data is buffered in one of the extra copying processes,
although the copying code tries to decrease the lieklyhood for that,
it doesn't read until the destination appears to be writable.
One can tune this by providing an argument to --cvs-workaround,
recognized characters are o (stdout), e (stderr), i (stdin), and for
example --cvs-workaround=io will do the extra copying for stdin and
stdout, but not stderr.
Hmm. Searching through my old mail, it has been reported that
--cvs-workaround=oe seemed to solve the problem for lsh-1.1.2. Is that
still the case? And are both o and e needed?
I don't quite understand the interaction with cvs; I can understand if
cvs shares stderr with lsh, but does it also share stdout???
/Niels
