Chet has since pointed out that the debugger is not involved at all. On Mon, 22 Jan 2024, 18:17 Grisha Levit, <grishale...@gmail.com> wrote:
> > That's not quite what happens. These scripts get executed by forking the > current bash process (without exec). The new shell resets its state and > runs the script. > I'm broadly aware that this is what happens; however it's not impossible that such could be handled by a short script built into the Shell, rather than as native C code. The debugger message is afaict an artifact of not quite resetting > completely -- if you had extdebug on in the shell from which you ran `./b`, > the forked shell will try to load the debugger start file (as when running > `bash -O extdebug ./b`) > Okay that makes sense; I leave extdebug turned on in my interactive Shell so that caller will report more info. Note that the script still runs, `B` is printed. > Yeah I saw that. So these are both sides effects of the same thing: not properly resetting the Shell state when creating an interpreter for a script without a #! -Martin >
