Broken process substitution

Daniel Colascione
Fri Aug 13 20:56:00 GMT 2010

On Fri, Aug 13, 2010 at 1:44 PM, Daniel Colascione
<> wrote:
> On Fri, Aug 13, 2010 at 1:25 PM, Eric Blake <> 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:

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.


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:
Unsubscribe info:

More information about the Cygwin mailing list