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

[Dan Douglas]

On Monday, October 06, 2014 02:00:47 PM Linda Walsh wrote:
> 
> Greg Wooledge wrote:
> > On Mon, Oct 06, 2014 at 12:38:21PM -0700, Linda Walsh wrote:
> >> According to Chet , only way to do a multi-var assignment in bash is
> >>
> >> read a b c d  <<<$(echo ${array[@]})

It's best to avoid turning your nice data structure into a stream only to read 
(and mangle) it back again.

If you must, create a function.

    function unpack {
        ${1+:} return 1
        typeset -n _arrRef=$1 _ref
        typeset -a _keys=("${!_arrRef[@]}")
        typeset -i n=0
        shift

        for _ref; do
            ${_keys[n]+:} return
            _ref=${_arrRef[${_keys[n++]}]}
        done
    }

#  $ a=(1 2 3) e=hi; unpack a b c d e; typeset -p {a..e}
# declare -a a='([0]="1" [1]="2" [2]="3")'
# declare -- b="1"
# declare -- c="2"
# declare -- d="3"                                                              
                                                                                
                                  
# declare -- e="hi"

> Um... it used a socket.. to transfer it, then it uses a tmp file on top
> of that?!  :

That's the wrong process. AF_NETLINK is the interface used by iproute2 for IPC 
with the kernel. Bash doesn't use netlink sockets.

> >> So why would someone use a tmp file to do an assignment.
> > 
> > It has nothing to do with assignments.  Temp files are how here documents
> > (and their cousin here strings) are implemented.  A here document is a
> > redirection of standard input.  A redirection *from a file*
> ----
>       Nope:
>   This type of redirection instructs the shell to  read  input  from  the
>         current source until a line containing only delimiter (with no 
trailing
>         blanks) is seen.  All of the lines read up to that point are then  
used
>         as the standard input for a command.
> 
> "The current source" -- can be anything that input can be
> redirected from -- including memory.
> 
> 
> > in fact,
> > albeit a file that is created on the fly for you by the shell.
> ----
> Gratuitous expectation of slow resources...  Non-conservation
> of resources, not for the user, but for itself.
> 
> Note:
> > a=$(<foo)
> > echo "$a"
> one
> two
> three
> ---
> no tmp files used, but it does a file read on foo.
> 
> b=$a
> -- the above uses no tmp files.
> 
> b=$(echo "$a")
> ---
> THAT uses no tmp files.
> 
> But
> b=<<<$a
> 
> uses a tmp file.
> 
> That's ridiculously lame.

That isn't working code the way you think (except in mksh). In most shells its 
just a null command that sets b to empty.

Just perform the assignment directly. There's no need for any special 
expansion or redirect.

> >> So why would a temp file be used?
> > 
> > Historical reasons, and because many processes will expect standard input
> > to have random access capabilities (at least the ability to rewind via
> > lseek).  Since bash has no idea what program is going to be reading the
> > here document, why take chances?
> ----
>       How could you use a seek in the middle of a HERE doc
> read?
> 
> Not only that, it's just wrong.    /dev/stdin most often comes from
> a tty which is not random access.

There is no requirement for how heredocs are implemented. Temp files are 
perfectly reasonable and most shells use them. The shell reads the heredoc, 
but it is the command that would be doing any seeking, or possibly the shell 
itself via nonstandard features like the <#(()) redirect.

This can be an optimization. Consider:

for file in file1 ... filen; do
    ed -s "$file" </dev/fd/0
done <<\EOF
ed script...
wq
EOF

In the above case, bash doesn't actually have to re-create the input 
repeatedly, it just creates a new FD, effectively rewinding the input.

-- 
Dan Douglas