Re: ${| command; } funsub not setting REPLY does not error out with 'set -u' active

[Zachary Santer]

On Mon, Dec 23, 2024 at 11:50 AM Chet Ramey <chet.ramey@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.
>
> > 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.
>
> Bash knows what to do when a funsub leaves REPLY unset as well.

Currently the same thing it would do with a regular parameter
expansion of an unset variable if 'set -u' were disabled: expand it to
the empty string.

> Maybe
> the best way to think about it is COMPREPLY. Leaving COMPREPLY unset is
> a valid, if unusual, way to indicate that there are no possible
> completions.
>
> In the same way, leaving REPLY unset in a funsub is a valid, if unusual,
> way to indicate that the funsub produces no output.

And people who don't use 'set -u' might consider leaving a variable
unset to be a perfectly valid way to indicate that it should expand to
the empty string. People who use 'set -u', on the other hand, have
accepted that they need to set such variables to the empty string, or
expand them with ${variabble-} if that's the best way to handle that
particular variable. Just the price to pay to have the shell do a
little more checking for you. I would argue the same applies to ${|
command; }. The developer who uses 'set -u' would know they need to
set REPLY to the empty string within the funsub if they want the
funsub to expand to that.

> Command substitutions produce no output all the time.

Commands being run within a command substitution or ${ command; }
funsub have no other way to indicate that they should expand to
nothing besides printing nothing to stdout. There's no variable to
reference that could either be unset or set to the empty string, so
there's no distinction to make. If the command encounters an error, it
can print an error message to stderr and exit with a nonzero status,
the same things bash does with 'set -u' enabled upon attempting to
expand the value of an unset variable. If you consider such an
expansion to be an error, this is what you want.

The following expansions have effectively the same error:

: ${
  local REPYL="whatever"
  printf '%s\n' "${REPLY}"
}

: ${|
  REPYL="whatever"
}

But 'set -u' currently leads to only the first one erroring out.

> > 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.
>
> You still have to check whether REPLY expands to the empty string. How
> is that different?

REPLY expanding to the empty string would be fine. The script set it to that.

> This sounds like something a tool like `shellcheck' should warn about.

I'd imagine shellcheck warns about other attempts to expand unset
variables too. No reason 'set -u' shouldn't work.

...

Some other nonsense real quick:

zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ : ${|  REPYL="whatever"}
; }
bash: syntax error near unexpected token `;' while looking for matching `}'
bash: DEBUG warning: current_token (10) != shell_eof_token (})
bash: syntax error

zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ : ${|  REPYL="whatever"; }
bash:  : command not found

zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ : ${| REPYL="whatever"; }
bash:  REPYL=whatever: command not found

zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ : ${| REPYL="whatever"; }
bash:  REPYL=whatever: command not found

zsant@Zack2021HPPavilion MSYS ~/repos/bash
$ : ${|
 REPYL="whatever"
}

The first thing within a ${| command; } funsub has to be a command if
it's on the same line as ${| ?

Git commit f223b24c4b.