On Tue, Dec 24, 2024 at 12:10 PM Zachary Santer <zsan...@gmail.com> wrote:
>
> On Mon, Dec 23, 2024 at 11:50 AM Chet Ramey <chet.ra...@case.edu> wrote:
> >
> > On 12/20/24 11:04 AM, Zachary Santer wrote:
> >
> > > Explicitly attempting to expand any one of those with a parameter
> > > expansion when it's unset and 'set -u' is active will cause bash to
> > > error out. ${| command; } is likewise also an explicit attempt to
> > > expand the value of a variable, this time the instance of REPLY local
> > > to the funsub.
> >
> > Your view of `explicit' is, um, unorthodox.
Maybe this is a better distinction to draw:
name=value
[...]
: "${name}"
and
: "${|
[...]
REPLY=value
}"
both represent the combination of an assignment and an expansion
communicating information from point to point within the script being
run.
PS2, PS4, GLOBIGNORE, COMPREPLY, etc., are primarily there to
communicate information to the bash interpreter itself, which causes
it to behave in a certain way more generally.
Separately, I imagine the ${| command; } form of a funsub is a
reflection of an existing design pattern for reusable functions to
assign their output to a REPLY variable to pass that output back to
the caller without the cost of forking a subshell to collect printed
output in a $( ) command substitution.
Using this design pattern, without using ${| command; }, it would
actually be kind of dangerous for the function to leave REPLY unset,
even if set -u isn't in use.
local REPLY
func1 arg1 arg2
local func1_out="${REPLY}"
func2 arg3 arg4
local func2_out="${REPLY}"
Now imagine func1 set REPLY and func2 didn't. The calling code is
going to take func1's output to also be func2's output. The only way
to avoid this would be to unset REPLY between function calls.
Not sure if that's really an argument for anything, but it came to mind.
