bug-bash
[Top][All Lists]
Advanced

[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: Mon, 06 Oct 2014 23:07:30 -0700
User-agent: Thunderbird



Pierre Gaston wrote:

b=<<<$a is not doing anything so I wonder how much value this example has.
---
I wondered about that.. think that was meant to be the
b=<<<($a) w/o the copy that greg said was pointless.

A pipe means 2 different processes, a tempfile for a heredoc does not.
----
First) we are talking 2 separate processes...
That I fit those into a heredoc paradigm was already a kludge.

originally I had, (and wanted)

producer-func  call it prod()
and process-func+store-in-global for future

i.e. producer|process-func -> vars... but I want the vars in the parent... so

processfunc <|<(producer) -- now process can store results but it's using
bogus magic called "process substitution"... naw...
it's a LtR pipe instead of a RtL pipe. or

parent <|<(child) pipe

instead of the standard:

child|parent pipe.   The parent being the one who's vars "live" on
afterwards.

I thought I was getting rid of this bogus problem (which shouldn't
be a problem anyway -- since it's just another pipe but with parent receiving
the data instead of child receiving it) by storing it in a variable transfer 
form
<<<($VAR)... cuz was told that didn't involve a voodoo process-substitution.

But it involves a heredoc that even though /tmp and /tmp/var are writeable,
BASH can't use.  Either it's writing to //network or trying to open a
tmp file in the current (/sys) directory... eitherway is buggy.

But a heredoc is just reading from an in-memory buffer.  That bash is
going the inefficient route and putting the buffer in "tmp", first, is
the 2nd problem you are pointing out -- why do people who want a heredoc
need a fork OR a tmpfile?   The output I generated is < 512 bytes.  Would it
be too silly to simply put any heredoc output <X[KMG]** in memory and not
write it to any file?  shopt heredocsize=XXX[KMG]... and overflow to tmp
if needed.

But more basically (no limits need be implemented):
why there is there a difference between :

parent producer >|> child reader
   vs.
parent reader <|<  child producer

???

If you want to ask your Q, you should be asking why fork OR *tmpfile.

In my case, Why do I need a voodoo process that can't be done with pipes..
cuz I'm pretty sure a parent can spawn children and then read from them
just as easily as write to them.





Besides your comparison is simply ludicrous, bash provides several
mechanisms do to several very different things.
---
Having several that would work woudl be nice.  Um... having 1 that would
work even... how do you turn around parent/child I/O and get the vars on the
other side without heredoc or procsub?  Why no pipes?




reply via email to

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