On Thu, Dec 19, 2024 at 11:08 AM Chet Ramey <chet.ra...@case.edu> wrote:
>
> On 12/18/24 9:39 PM, Zachary Santer wrote:
>
> > If one wants to use funsubs that don't expand to anything as a
> > workaround like this, it might be more efficient to use the ${|
> > command; } form, as bash then isn't pointlessly redirecting stdout.
> >
> > The manual describes 'set -u'/'set -o nounset' thusly:
> > Treat unset variables and parameters other than the special parameters
> > “@” and “*”, or array variables subscripted with “@” or “*”, as an
> > error when performing parameter expansion. If expansion is attempted
> > on an unset variable or parameter, the shell prints an error message,
> > and, if not interactive, exits with a non-zero status.
>
> 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.
By contrast, the expansions of, or other references to, variables like
PS2 and PS4 that bash makes internally are implicit. For many of the
variables listed in that portion of the "Shell Variables' section of
the manual, It's a perfectly valid state for them to be left unset.
You don't always need a TMOUT, an LC_ALL, or a FUNCNEST, for instance.
Bash knows what to do without them.
>From a more practical perspective, if a user uses ${| command; }, they
most likely intend to expand the value of REPLY local to the funsub,
given that's the purpose of this expansion. Something like my usage to
collect the PIDs of multiple procsubs being forked in one command or
set of redirections would be well outside the norm.
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 and leave me scratching my head as to what's going on,
given breakage potentially evident only later in the script.
