Re: turning on file+line for functions with shopt -s extdebug gives error

[L A Walsh]

On 2/25/2019 6:53 AM, Chet Ramey wrote:
> Setting debugging mode in one of the startup files is an alternate way
> to start the bash debugger, equivalent to invoking bash with --debugger.
> It's been that way since the debugging support was introduced in bash-3.0.
>   
I suspected that given the behavior.

FWIW, I've found the debugger to be an impressive bit of
of shell programming.

However, I'm running into problems when I want to have it
debug some of my more esoteric bits of shell.

Where it really falls apart is when it tries to trace through
functions that were created at login before the debugger started.

I was hoping to give it a nudge or help it a bit by ensuring that
the filename and line-number of functions was stored for _all_
functions.  That way, at least in my case, it would be able, potentially
to access the original source of those functions later on.

It also might have an advantage to Bash in error reporting: when
bash runs into an error in a function, error messages that contain
a line number often will have a line number relative to the function
rather than the file.

In looking at the bash manpage, I find that 'extdebug' documents
the turning on and saving of source and line numbers, but I don't
see where it documents running the bash debugger.

Nor do I see where function-tracing and error tracing are defined.

Are they defined "somewhere"?  Maybe a short note as to what they
are might be added to the manpage where the terms are used (under
description of shopt+extdebug)?

Would it be possible to have a way to turn on source+lineno saving
for functions, all the time so they'd be available to -F, otherwise
trying to single step though any of those functions becomes
impossible. 

The unpatched debugger also tends to emit many error messasges
even when trying to bypass those functions, say, by using a
breakpoint in a debugged script that is past the point where they
are called.

Locally, I disabled the error message, but that really should
be done in the main copy.  In my copy I just commented
it out:

--------
> diff -u filecache.sh.orig filecache.sh
--- filecache.sh.orig 2017-06-08 17:08:57.000000000 -0700
+++ filecache.sh  2019-02-15 17:00:35.764786734 -0800
@@ -122,7 +122,7 @@
 # '' is echo'd if no file found. Return 0 (in $?) if found, 1 if not.
 function _Dbg_is_file {
   if (( $# == 0 )) ; then
-    _Dbg_errmsg "Internal debug error _Dbg_is_file(): null file to find"
+    #_Dbg_errmsg "Internal debug error _Dbg_is_file(): null file to find"
     echo ''
     return 1
   fi
@@ -130,7 +130,7 @@
   typeset try_find_file
 
   if [[ -z $find_file ]] ; then
-    _Dbg_errmsg "Internal debug error _Dbg_is_file(): file argument null"
+    #_Dbg_errmsg "Internal debug error _Dbg_is_file(): file argument null"
     echo ''
     return 1
   fi
-------

I don't know what the usefulness of that message is, but it didn't
seem to serve any purpose other than telling me that the source+line
of functions defined before the debugger was started aren't known
about. 

Unfortunately, even with the source+lineno present for those
functions, it doesn't seem to use that information to try to read
the function source if those functions are encountered later.
That's something that I might hope can be addressed.

Additionally, it would be very useful if there was a way of storing
the original source's format, as a 'backup' to being able to read
the original source of the function.

One could debug function without the source IF there was some way
to list out the in-memory form of the function with line numbers,
though that is a bit of an awkward requirement when single stepping.

Nevertheless, despite its shortcomings, the debugger is impressive
for what it does in pure shell.

Linda