On Mon, May 18, 2026 at 3:48 PM Chet Ramey <[email protected]> wrote:
>
> Bash aborts "the command in which the error occurred," which is the
> function call, and returns to the top level to read the next command.
"[D]oes not execute the command associated with the expansion" sounds like, with
$ printf '%s\n' "${unset_var:?}"
the printf call isn't executed. If you're halfway through a function
when you get to this parameter expansion, there's no taking back
what's already executed.
If you're changing that language in the manual to "the command in
which the error occurred," that does seem like a reasonable catch-all.
I just don't really think of function calls as commands.
> Since it's sourcing the file and reading commands from it one at a
> time, it returns to the current top level and reads the next command
> from the sourced file.
An argument could be made that the command line with a prompt is the
true "top level" here. That's where you return to after you're done
sourcing the file, after all.
