[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Weird process substitution behavior
From: |
Chet Ramey |
Subject: |
Re: Weird process substitution behavior |
Date: |
Sat, 16 Nov 2013 13:39:06 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 |
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/