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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
