Re: svn client with ssh: data loss in output when both stdout and stderr are redirected to a pipe

On 2011-05-30 09:58:45 -0400, Mark Phippard wrote:
> 2011/5/30 Vincent Lefevre <vincent-svn_at_vinc17.net>:
> > I've found the following bug with Subversion 1.6.16:
> >
> >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627025
> >
> > The problem is: With the svn+ssh scheme, a ssh process is started and
> > sets its stderr to non-blocking mode. When executing an API-based svn
> > client with both stdout and stderr redirected to a pipe, output to
> > stdout (and stderr too, I suppose) fails with EAGAIN instead of
> > blocking when the pipe buffer is full. See the above URL for more
> > information.
> >
> > "svn log 2>&1 | less" on a (big enough) svn+ssh working copy fails to
> > output the full log. It sometimes ends with:
> >
> >  svn: Write error: Resource temporarily unavailable
> >
> > I think the above test should be sufficient, but just in case, I've
> > attached (this is what I used for my Debian bug report):
>
> This sounds similar to this bug:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=3014

No, this is a different bug.

Bug 3014 is about an error message printed instead of using the
exit status to signal the broken pipe. The broken pipe is normal,
and it occurs even when stderr is not redirected to stdout, and
even without ssh.

In my bug report above, there should be no broken pipe or any
other error (as long as one uses "less" + [End] key, or some
command like wc, which reads the full input stream). It occurs
only when stderr is redirected to stdout, and only when ssh is
used (as in the svn+ssh scheme).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)