[Top][All Lists]

[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


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)


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]