Re: Weird process substitution behavior

[Chet Ramey]

On 11/8/13, 6:26 PM, John Dawson wrote:
> The following surprised me. I thought line 4 of the output, and certainly
> line 5 of the output, should have said "0 /dev/fd/63" too. Is this behavior
> a bug?

Bash is pretty aggressive about closing pipe file descriptors (/dev/fd
constructs use pipes) opened for read.  Open pipe file descriptors inhibit
SIGPIPE sending.  In this case, the pipe fd gets closed in the parent part
of the pipeline, and is therefore unavailable for the next command in the
shell function.  The pipeline error (line 4) is the issue discussed in

http://lists.gnu.org/archive/html/bug-bash/2012-11/msg00013.html

That was fixed a while back.  The fix for the shell function issue is to
defer closing the named pipes until the shell function returns.  I will
have to see whether or not that causes file descriptor exhaustion under
the right scenario.

> 
> $ cat bug1.bash
> #!/bin/bash
> count_lines()
> {
>     wc -l $1
>     wc -l $1
>     wc -l $1
>     true | wc -l $1
>     wc -l $1
> }
> count_lines <(date)

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/