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

[Greg Wooledge]

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[@]})

The redundant $(echo...) there is pretty bizarre.  Then again, that
whole command is strange.  You have a nice friendly array and you are
assigning the first 3 elements to 3 different scalar variables.  Why?
(The fourth scalar is picking up the remainder, so I assume it's the
rubbish bin.)

Why not simply use the array elements?

> Forcing a simple assignment into using a tmp file seems Machiavellian --
> as it does exactly the thing the user is trying to avoid through
> unexpected means.

You are working in a severely constrained environment.  Thus, you need
to adapt your code to that environment.  This may (often will) mean
you must forsake your usual practices, and fall back to simpler
techniques.

I don't know precisely what your boot script is attempting to do, or
precisely when (during the boot sequence) it runs.  Nor on what operating
system you're doing it (though I'll go out on a limb and guess "some
flavor of Linux").

Maybe the best solution here is to move your script to a different part
of the boot sequence.  If you run it after all the local file systems
have been mounted, then you should be able to create temporary files,
which in turns means << and <<< become available, should you need them.

> The point of grouping assignments is to save space (in the code) and have
> the group initialized at the same time -- and more quickly than using
> separate assignments.

Elegance must be the first sacrifice upon the altar, here.

> 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*, in fact,
albeit a file that is created on the fly for you by the shell.

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

> Creating a tmp file to do an assignment, I assert is a bug.

You are not *just* doing an assignment.  You are doing a redirection.
Furthermore, you have not even demosntrated the actual reason for the
here document yet.

> cmd1 | cmd2 -- that hasn't used tmp files on modern *nix systems for
> probably 20 years or more (I think DOS was the last shell I knew that used
> tmp files...)

Correct.  Pipelines do not use temp files.

> so why would "cmd2 < <(cmd1 [|])" not use the same paradigm -- worse, is

Process substitution uses either a named pipe, or a /dev/fd/* file system
entry, or a temp file, depending on the platform.

> cmd1 >& MEMVAR   -- output is already in memory...

Now you're just making things up.  That isn't bash syntax.

> so why would read a b c <<<${MEMVAR} need a tmp file if the text to be
> read is already in memory?

Because you are using generalized redirection syntax that is intended
for use with *any* command, not just shell builtins.

Your example has now changed, from   read a b c d <<< "${array[*]}"
to   read a b c <<< "$scalar"

I don't know which one your *real* script is using, so it's hard to
advise you.

If you want to replace the former, I would suggest this:

a=${array[0]}
b=${array[1]}
c=${array[2]}
d="${array[*]:3}"

If you want to replace the latter, I would suggest something like this:

shopt -s extglob
temp=${scalar//+([[:space:]])/ }
a=${temp%% *}
temp=${temp#* }
b=${temp%% *}
c=${temp#* }

This may be overkill, since the consolidation of whitespace might not
be necessary.  It's impossible to tell since you have not shown the
actual input, or the actual desired output, or even used actual variable
names in your examples.