Re: Lost process output in pipe between Emacs and CVS

[Derek Robert Price]

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.

Derek

--
               *8^)

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