On Mon, Jul 17, 2023 at 8:14 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> I have not yet implemented the anonymous tempfile for ${
> capture_stdout }.  However, this equivalent construction does work
> (extra newlines for clarity):
>   ${|
>     () {
>       capture_stdout > $1
>       REPLY=$(<$1)
>     } =(</dev/null)
>   }
>
> Both $(<...) and =(<...) are non-forking shortcuts already, so this
> acts as proof of concept.

I've just discovered that =(<file) is NOT in fact non-forking.  Only
=(<<<string) is non-forking.  Any particular reason for this?  It has
the weird-feeling effect that =(<<<$(<file)) is non-forking whereas
the simpler construction is not.  In any event, =(<<<'') can be
substituted in the example above, and avoids opening /dev/null so is
preferable as well.

Which is exactly what the appended patch does:  Leverage
getoutputfile() to create a temporary name, then write it and read it
back.

Implementation question:  It seems to be OK to tokenize() a string
that has already been tokenize()d?  I tried to avoid double-tokenizing
with ${| ...} by checking whether the "|" was already tokenized as
"Bar", but there's no such hint available with ${ ... }.  It
nevertheless seems to work.

Tests are minimal because this all just falls through to the REPLY
case that's already being thoroughly tested.  Unless the
double-tokenize thing could break something.