Date: Fri, 10 Feb 2012 21:20:12 GMT From: Diomidis Spinellis <dds@aueb.gr> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/164947: tee looses data when writing to non-blocking file descriptors Message-ID: <201202102120.q1ALKCGp091543@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/164947; it has been noted by GNATS. From: Diomidis Spinellis <dds@aueb.gr> To: Martin Cracauer <cracauer@cons.org> Cc: freebsd-gnats-submit@freebsd.org Subject: Re: bin/164947: tee looses data when writing to non-blocking file descriptors Date: Fri, 10 Feb 2012 23:17:03 +0200 On 10/02/2012 23:03, Martin Cracauer wrote: > Diomidis Spinellis wrote on Fri, Feb 10, 2012 at 10:32:02PM +0200: >> On 10/02/2012 21:17, Martin Cracauer wrote: >>> Diomidis Spinellis wrote on Fri, Feb 10, 2012 at 07:04:41AM +0000: >>>> >>>>> Number: 164947 >> [...] >> >>>>> How-To-Repeat: >>>> Run the following: >>>> #!/usr/local/bin/bash >>>> # bash needed for the>(...) functionality >>>> # ssh apparently sets O_NONBLOCK >>>> # Remove the 2>/dev/null to see tee complaining >>>> dd count=100000 if=/dev/zero | >>>> tee>(ssh localhost dd of=/dev/null) 2>/dev/null | >>>> (ssh localhost dd of=/dev/null) >>> >>> I don't think it is ssh that is causing this. If you use a named pipe >>> explicitly and hook ssh up to that the error doesn't appear. Seems to >>> be something that bash is doing there. >> >> I think the named pipe isolates the write fd from the ssh end. If you >> use cat or dd instead of ssh the problem goes away. > > Do you happen to know what bash does there, exactly? I was assuming it > is creating a named pipe behind the user's back. It is creating a normal pipe and providing it as an argument through /dev/fd. Try ls -l /dev/fd >(wc -l) > I noticed that if you do ssh on the "tee part" and something else on > the end of the regular pipe then things also fail. On the other hand > if you put the "tee part" on something else and the regular pipe on > ssh things never seem to fail. On 8.1 release I needed both ends to run ssh to see the problem. BTW The problem also manifests itself on Mac OS X and Linux :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201202102120.q1ALKCGp091543>