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