[Top][All Lists]

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

Re: Lost process output in pipe between Emacs and CVS

From: Derek Robert Price
Subject: Re: Lost process output in pipe between Emacs and CVS
Date: Wed, 24 Jul 2002 13:10:34 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606

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 even while the output is blocked, it won't do that.
'less' will, and possibly some (not all) versions of 'more'.

'cat' relies on the stdin and stdout block buffers just like all other
unix i/o programs.

This wouldn't be a problem. The problem is that in a standard configuration:

          --stderr->     -------------stderr------------>
         /          \   /                     /          \
CVS Server            ssh            CVS client            tty
         \          /   \          /          \          /
          --stdout->     --stdout->            --stdout->

Note that since CVS didn't access the stderr of its child process, ssh, the child process gets a clone of the parent process' stderr descriptor and ssh and the CVS client end up sharing the tty's standard error.

Now, when the user redirects stderr to stdout, say, to redirect the output to a file (e.g. CVS_RSH=ssh cvs diff >tmp.diff 2>&1), you get the following configuration:

          --stderr->     -------------stderr-------------
         /          \   /                     /          \
CVS Server ssh CVS client -->tty/file/whatever
         \          /   \          /          \          /
          --stdout->     --stdout->            --stdout--

Since CVS was using the same file descriptor for stderr and stdout, ssh is writing to CVS's stdout descriptor as its stderr. When ssh sets its stderr to non-block, the same happens to CVS's stdout. Since CVS isn't prepared for this, data gets lost (written to a non-blocking descriptor without watching for EAGAIN).

so if you're looking for a utility to do i/o buffering for you, cat
isn't it.

So, anyway, cat wouldn't need to do line buffering. What has been proposed is that a script stick cat in between ssh's stderr and cvs's stderr. I assume by redirecting ssh's stderr to cat's stdin and then cat's stdout back to CVS's stderr, but I'm going to leave stdin out of the following picture for convenience:

          --stderr->     --stderr----->cat-------stderr--
         /          \   /                     /          \
CVS Server ssh CVS client -->tty/file/whatever
         \          /   \          /          \          /
          --stdout->     --stdout->            --stdout--

Now, when ssh sets its stderr to O_NONBLOCK, only cat's stdin will be affected. cat's buffering ability will be irrelevant since ssh is the only PROCESS that needs to be aware of the non-blocking i/o and resend data and it is already doing that.



Email: derek@2-wit.com
Public key available from www.keyserver.net - Key ID 5ECF1609
Fingerprint 511D DCD9 04CE 48A9 CC07  A421 BFBF 5CC2 56A6 AB0E

Get CVS support at http://2-wit.com
The advertisement is the most truthful part of the paper.

                        - Thomas Jefferson

reply via email to

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