bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making "cmd< <(...)" useful (reliable)


From: Chet Ramey
Subject: Re: Making "cmd< <(...)" useful (reliable)
Date: Mon, 30 Jun 2014 12:37:24 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

On 6/29/14, 4:47 PM, Linda Walsh wrote:

> Is it possible to make that feature work, by default, w/o the unreliable
> part?  I.e. in < <(xxx).  Can't the part in (xxx) be forked into a child
> that has it's output fed into the parent?

It doesn't sound like you understand how this construct works.  The part
within the parens is already run in a subshell, and communicates with its
parent shell using pipes.

> 
> Right now we have (case 1):
> xxx|yyy|zzz for running "xxx" and "yyy" in children with "zzz" in a parent.

Yes, though not by default, and not when job control -- with its dependence
on all members of a pipeline being in the same process group -- is enabled.
In the general case, `zzz' is run in a subshell.

> 
> So is there a reason for not doing similar for < <()?

Let's go through how this works.  The <(command) is a word expansion that
results in a filename.  As above, `command' is executed in a subshell and
communicates with its parent through pipes.  The filename is a way of
making the internal pipe file descriptors the parent uses to communicate
with `command' explicit by naming them in the file system.  Turning pipe
file descriptors into file names needs a way to have `named pipes' (FIFOs)
or a way to reference open file descriptors using the file system
(/dev/fd).

So the difference between your case 1 and case 2 is that case 1 uses
`anonymous' pipes duplicated onto standard input and standard output, and
case 2 uses file descriptors outside the 0-2 range which are named
explicitly and available to the command as a filename argument.

What you're complaining about is that the bash configure process makes the
decision about which file descriptor naming mechanism to use (FIFOs vs.
/dev/fd) at configure time rather than run-time.

If this is an issue serious enough to change how you write your code, you
should probably create and manage the FIFOs yourself using mkfifo and
explicit file descriptor manipulation.

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/



reply via email to

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