On Tue, Oct 7, 2014 at 2:07 AM, Linda Walsh <b...@tlinx.org> 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? > > >
