Re: Different variable assignments

In article <vec3qb$3q4ms$3@dont-email.me>,
Lawrence D'Oliveiro  <ldo@nz.invalid> wrote:

On Fri, 11 Oct 2024 22:50:10 +0200, Frank Winkler wrote:
>

... but it still doesn't solve the issue that I need the result to be
visible in the parent shell.

>
   coproc { uname -sr; }
   read -u ${COPROC[0]} var3
   wait $COPROC_PID
   echo $var3

I'm actually a fan of "coproc" in bash, and I use it in my scripting, but I
think it is overkill in most cases.  The most general command for variable
assignment (in bash) is "mapfile".  "mapfile" supercedes "coproc" in most
cases.  For the possible benefit of OP, here's the standard idiom for using
"mapfile", using the "sw_vers" program, which OP mentioned in passing
(AFAIK, "sw_vers" is a Mac OS thing):

    mapfile -t < <(sw_vers)

which populates the array MAPFILE.

A couple of other points:
    1) When using "coproc", you can get away with just $COPROC for the
    output of the co-process.  This is a little easier to type than
    ${COPROC[0]} - even if this does get flagged as a warning by the
    "shellcheck" program.  Note that in bash, all variables are arrays;
    it's just that most only have one element:
% bash -c 'echo ${HOME[0]}'
/home/me
%

    2) OP's main concern actually seems to be aesthetic.  He just wants the
    variable name at the end of the line instead of at the beginning.  Kind
    of like the difference between the two styles of assembler languages,
    where some are: "move src,dst" and others (most) are "move dst,src".
    (It's been a long time since I've done assembler language.)

Finally, note that you just generally learn to avoid the (wrong) idiom of:

    cmd | read bar

because you learn early on that it doesn't work.  I think the most basic
(works in any sh-like shell, even in the bad old days of Solaris)
alternative is:

    read bar << EOF
    $(cmd)
    EOF


--
https://www.rollingstone.com/politics/politics-news/the-10-dumbest-things-ever-said-about-global-warming-200530/

RS contributor Bill McKibben lambasted this analysis in his 2007 book, Deep Economy.
It's nice to have microelectronics; it's necessary to have lunch,  wrote McKibben.