Re: bash uses tmp files for inter-process communication instead of pipes?

[Chet Ramey]

On 10/7/14, 5:35 PM, Linda Walsh wrote:
> 
> 
> Chet Ramey wrote:
>> On 10/7/14, 1:45 PM, Linda Walsh wrote:
>>
>>> There is no fundamental reason why, say, process substitution needs to
>>> use /dev/fd or /proc/anything -- and couldn't operate exactly like piped
>>> processes do now.  On my first implementation of multiple IPC programs,
>>> I've used semaphores, message queues, named pipes, and shared memory.
>>> With the exception of using shared memory for mutiple megabytes of
>>> memory for each of several children, pipes provided equal or better
>>> performance.
>>
>> I think you have a fundamental misunderstanding of the purpose of
>> process substitution.  It is a way to turn a pipe to another process
>> into a file name, so that you can open what looks like a file,
> ----
> You mean "< <(process)" is the part you are saying looks like a file?
> 
> If it wasn't for the shell mangling eoln's why wouldn't <$(process) be the
> same?

OK.  Let's take a step back.  <(process) expands to a file name like
/dev/fd/26.  When you open that file for reading, you can read the output
of the process.  If you open it for writing, using the >(process) syntax,
you can write to the process's stdin.  This can be asynchronous, not
synchronous like pipes, and, since it can be combined with `exec' and a
redirection, you can save the file descriptor for later use.  In other
words, you can treat dynamically-generated data like a file.  That
filename isn't private to the shell; it can be used as an argument to
another program.

$(process) expands directly to the output of `process'.  Instead of
being able to read and process that data, it appears on the command line
as an expanded word.  You could make `process' output a filename that
the redirection opens, but that's not the same thing as dynamically
generating the data.

> Or are you saying that the shell not mangling eoln's is a way of making it
> look like a filei that you can use the normal set of !!!WRITE!!!...
> calls I can write to such a process?

This doesn't make any sense.

> 
> But I never got that < <(process) was anything more than a one way read
> from the
> right-hand process into the left -- and was not any different than
> (process)| .... where left hand process feeds into the right hand process.
> 
> I.e. both looked like unidirectional communication over a pipe.

They are superficially simimlar.  The < redirection is what makes it a
`one-way read'.  That's not the only thing you can do with a process
substitution.

> Both being cases where you can write to a process through a pipe.  I've
> used FIFO's but other than making it a bit easier to parse lines, they
> weren't much different than pipes -- which get parsed into lines all the time
> over the net et al.

Pipes are synchronous and anonymous.  Process substitution creates a
usable filename that you can use to communicate asynchronously with a
process.  They can be made to do the same thing, but are different.

-- 
``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/