On Fri, Dec 20, 2024 at 11:04:35 -0500, Zachary Santer wrote:
> On Thu, Dec 19, 2024 at 11:08 AM Chet Ramey <chet.ra...@case.edu> wrote:
> > So you're saying that bash looking at a specific variable and using its
> > value should fail if that variable is unset? How far do you want to
> > take that? PS2? PS4? GLOBIGNORE? COMPREPLY?
>
> 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.
I don't think your definition of "explicit" matches mine.
> So the purpose of 'set -u' still applies. If I, as the programmer,
> managed to misspell REPLY or forget to set it in some codepath, I'd
> rather bash tell me that than have it silently expand ${| command; }
> to nothing
I suppose that makes sense to the kind of person who'd use set -u in
the first place. However, a great number of shell functions don't
"return" anything (here, I'm talking about traditional ones, where the
"return value" is written to stdout to be captured in a command sub).
I don't think it makes sense for a script to error out by default if
a funsub expands to nothing, even when set -u is in effect. The odds
of the abort being undesirable there seem quite high.
