Closed jansorg closed 10 months ago
My guess is that these variables should be local
, because otherwise the state variables won't ever be reset. But I'm not sure I'm getting all of this code...
https://github.com/rocky/zshdb/blob/master/lib/processor.sh#L76-L77
IMHO executing an unknown or invalid command should only print an error and not resume execution.
I believe this is no longer the case, and was fixed around commit 713bb9350aa761c0a9a397396cafcb79471f6578.
My guess is that these variables should be local, because otherwise the state variables won't ever be reset. But I'm not sure I'm getting all of this code... https://github.com/rocky/zshdb/blob/master/lib/processor.sh#L76-L77
These are variables that are used by the debugger REPL loop to tell indicate whether on exit of the debugger read-eval-print we should go back into the debugged program or skip execution of the next zsh instruction of the debugged program.
I just looked at info variables
in zshdb
. It works differently, probably because this is the way zsh prefers to organize variable lookup. However the underlying command used in bash: declare -p
does exist and seems to do the same thing.
The bug reported by this issue seems to fixed with master. Closing this now.
The (bashdb-based) debugger integration of BashSupport Pro executes
info variables -p
to print variables. This command isn't yet available in zshdb (which is okay, I'll hopefully add it in a PR), but executing it resumes the execution of the debugged script. IMHO executing an unknown or invalid command should only print an error and not resume execution.