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, get a
file descriptor, use the normal set of read and write calls on it, and
all the while talk to another process. There are only a few ways to
do that, and /dev/fd and named pipes are really the only viable ones.
> It was certainly fun to try the various methods and compare them, but
> having an implementation that only depends on the LCD (pipes in this
> case), would make the code more portable and faster. For HEREDOC's
> there is no reason why chet couldn't use his own STDIO lib for the needs
> of bash that keep everything in memory or spill on extra large sizes.
Gosh, you mean I could write a stdio library that would have to be portable
over the whole set of systems on which bash currently runs and support it
forever, abandoning all the work vendors have done? It sounds too good to
be true!
> Design choice doesn't have to become feature constraint -- or if it
> does, then it's time to think about a different design choice. Then all
> of those features that currently use linux-only or linux-like extensions
> like proc and /dev/fd can be ported to platforms that don't support such
> a wide feature set.
/dev/fd (which I prefer to /proc) is not Linux specific. Named pipes are
standard.
--
``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/
