Re: :? within a function
Zachary Santer <[email protected]> Mon, 18 May 2026 17:36:17 -0400
| Newsgroups | gmane.comp.shells.bash.bugs,gmane.comp.shells.bash.help |
|---|---|
| Message-ID | <CABkLJUK+FdFW=waxiyC+d+xLxR2=rVRaDfXT3nBZ10z+hSv=aw@mail.gmail.com> |
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.