[Top][All Lists]

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

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

From: Linda Walsh
Subject: Re: bash uses tmp files for inter-process communication instead of pipes?
Date: Tue, 07 Oct 2014 14:35:26 -0700
User-agent: Thunderbird

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

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 
is broken, since I know the code, I have a reasonable chance of fixing it.  
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 
dev and proc were mounted and tmp is writeable.... but that's what tmp error 
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...

reply via email to

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