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

[Linda Walsh]

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?

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?  I've never seen this documented
where did I miss this... if that's the case, then I'll rethink my position.

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.

But if < <(process) has bidirectional communication, do you have an example
of this?.... Ahhh... you are referring to > >(process) which is like |(process)

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.

What read/write calls can you do with < <() > >() that you cannot with "|"'
that don't involve a "which process is on top" paradigm (which, as you mention,
is switchable with "lastpipe" anyway)?


> 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!
----
        I can let you use mine but it's specific to my use case and partly
in c++ which I'm learning as I work on something.  But the specific to use
case is also the point.  You don't need the whole set to buffer IPC in memory.

        I generally prefer my own code and utils because their interfaces are
relatively stable compared to my needs -- BUT MOST of all -- because if 
something
is broken, since I know the code, I have a reasonable chance of fixing it.  
That's
harder to say picking up other people's stuff -- IF that is even an option.

        FWIW -- I went back to using process substitution because I don't
know where the tmpfiles are opening (TMP and TMPFILE are not set, and /tmp
and /var/tmp are/were both writeable).  Now it is working.

        None of the problems had to do with any of the IPC methods but with
what appeared to be a secondary declaration of the global variables in
a sub... hiding the globals.

        I couldn't see what I was doing that would have caused problems since 
both
dev and proc were mounted and tmp is writeable.... but that's what tmp error 
message
seemed to think.

        Even though it's a startup script, it's not starting up the kernel --
its renaming and reordering network interfaces to suit the user's choice.

        Responses on other stuff  later...