On Jul 29 17:23, Corinna Vinschen wrote:
> On Jul 29 14:26, Ken Brown wrote:
> > On 7/29/2019 9:47 AM, Corinna Vinschen wrote:
> > > On Jul 29 13:18, Ken Brown wrote:
> > >> $ strace -o trace.out ls -lL <(grep bash .bashrc)
> > >> ls: cannot access '/dev/fd/63': No such file or directory
> > > 
> > > No, please run bash:
> > > 
> > >    strace -o trace.out bash -c 'ls -lL <(grep bash .bashrc)'
> > > 
> > > Otherwise there's no process actually creating the pipe, given the <()
> > > expression is a bash expression.
> > 
> > Yes, of course.  I should have realized this since it's exactly what I
> > did under gdb.  Anyway, the result is the same as it was under gdb: If
> > I run the command under strace, I don't see the broken pipe error.
> > 
> > Is it possible that debugging causes an fd to the read end of the pipe
> > to stay open longer, thereby preventing the error?
> 
> The fact that you observe it sporadically points to a race condition.
> Debugging serializes stuff usually running in parallel, potentially
> eliminating the race.

Is there any chance this is a BLODA problem?  If /dev/fd/63 doesn't
exist in ls, it would mean ls didn't inherit the FIFO, which sounds
very unlikely.  I ran the ls call in a loop a couple of 1000 times,
even in parallel windows including xterm and I just can't reproduce.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer