This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Broken process substitution
On Fri, Aug 13, 2010 at 1:44 PM, Daniel Colascione
<dan.colascione@gmail.com> wrote:
> On Fri, Aug 13, 2010 at 1:25 PM, Eric Blake <eblake@redhat.com> wrote:
>> 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.
>> But that's highly likely that you are dealing with yet another one of
>> cygwin's pipe handling shortfalls.
>
> Would these shortfalls also explain why this script doesn't do what
> I'd expect (that is, output "hello" and exit)? It just hangs right now
> --- this is the ps output:
Actually, the seemingly-equivalent version below works fine. Maybe
there was a race between the cygpath's starting to read the fifo and
the last line starting to write to it.
The *real* bug seems to be triggered by the following commands:
#!/bin/sh
cd /tmp
mkfifo blah
( echo hello > blah )&
cat blah
On other systems (OS X and Linux), that just outputs "hello", then
both processes exit. On Cygwin, the writer is blocked indefinitely and
has to be SIGKILLed --- even if a reader then starts. And the reader
acts as if there were no writer at all.
--------
#!/bin/bash
set -e
tmpdir=$(mktemp -dt cygfilter-XXXXXX)
function cleanup() {
rm -rf "$tmpdir"
}
trap cleanup 0
mkfifo "$tmpdir/f-out"
mkfifo "$tmpdir/f-err"
cygpath -u -f- < "$tmpdir/f-out"&
cygpath -u -f- < "$tmpdir/f-err" >&2 &
"$@" >"$tmpdir/f-out" 2>"$tmpdir/f-err"
--
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