The following reply was made to PR bin/164947; it has been noted by GNATS. From: Diomidis Spinellis <[email protected]> To: Martin Cracauer <[email protected]> Cc: [email protected] 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 :-) _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
