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: Dave Rutherford
Subject: Re: bash uses tmp files for inter-process communication instead of pipes?
Date: Tue, 7 Oct 2014 02:25:09 -0400

On Tue, Oct 7, 2014 at 2:07 AM, Linda Walsh <address@hidden> wrote:

>
>
> 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]