X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Sat, 14 Aug 2010 12:32:14 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Broken process substitution Message-ID: <20100814103214.GL14202@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <00c301cb3b22$ae416800$0ac43800$@gmail.com> <4C65A83F DOT 4010608 AT redhat DOT com> <4C65AA3A DOT 70303 AT redhat DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4C65AA3A.70303@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Aug 13 14:25, Eric Blake wrote: > On 08/13/2010 02:17 PM, Eric Blake wrote: > > On 08/13/2010 02:04 PM, Daniel Colascione wrote: > >> Try "echo hello > >(cat)" -- that's supposed to output "hello". > > > > What makes you think it's supposed to echo hello? That's system > > specific on what will happen. According to the bash manual, > > > >> (cat) > > > > is evaluated first, and will result in a /dev/fd reference, or a named > > pipe (it so happens that it is a /dev/fd reference in cygwin). But this > > pipe is tied to the subprocess, so it only exists as long as the > > subprocess exists. > > Then again, cat should exist until something causes the input side of > its pipe to declare EOF; so I guess there's no race in this example > after all. Rather, it looks like a limitation in cygwin1.dll. I don't > know why bash is unable to duplicate the output end of the pipe to the > echo process, unless cygwin's /dev/fd handling doesn't work on pipes. I think I found the culprit in Cygwin. The problem occurs in writev. At the start of this function is a test which checks for the original open mode of the file descriptor. If it's O_RDONLY, the writev function errno set to EBADF. However, this doesn't make much sense, afaics. For one thing, if the underlying handle is really only readable, the underlying NtWriteFile function will fail anyway. And, for this pipe problem it seems to be in the way. If I remove this test, I get bash-3.2$ echo hallo > >(cat) bash-3.2$ hallo [...hangs here until any key is pressed...] bash-3.2$ That's the exact same behaviour as on Linux, afaics. However, I'm not sure just removing the test is really the right solution. I'll have to take a deeper look first. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple