This is the mail archive of the
mailing list for the Cygwin project.
Re: Broken process substitution
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)
[...hangs here until any key is pressed...]
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 Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple