On Fri, Dec 20, 2024 at 11:50 AM Greg Wooledge <g...@wooledge.org> wrote:
>
> 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.
${variable} and ${| command; } are explicit expansions in the sense
that I had to write them in the script for the expansions they specify
to be performed. As opposed to PS2, which bash will happily expand
without the user having to type ${PS2} anywhere.
> > 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.
I'm not saying anything about ${ command; }. My comments are specific
to the ${| command; } form. I agree that if what's present within ${
command; } doesn't output anything, that shouldn't trip 'set -u'.
