Please store source file name + line number for all functions defined whether or not bashdb is running.

[L A Walsh]

On 3/1/2019 8:00 AM, Chet Ramey wrote:
> On 2/27/19 4:19 PM, L A Walsh wrote:
>   
>
> BASH_SOURCE and BASH_LINENO are available even when the debugger is
> not running, as is the `caller' builtin.
----
They are available, but have the wrong information.  Though for the current
line number shouldn't one use 'LINENO'?  Example:
(with
PS4='>${BASH_SOURCE:+${BASH_SOURCE/$HOME/\~}}#${LINENO}${FUNCNAME:+(${FUNCNAME})}>')

>apply_patch#9> include stdalias
>>environment#0(include)> :
>>environment#0(include)> :
>environment#0(include)> [[ -n stdalias ]]
>>environment#1(include)> :
>environment#1(include)> local fnc=stdalias.shh
>>environment#2(include)> :
>environment#2(include)> [[ s == \/ ]]
--------
Note that BASH_SOURCE does not show the name of the file you are
tracing through.  Also, the line number is from the start of the function
that was called -- not from the start of the file.

At this point, the source and line of where the traced code comes from
(in bashdb as well) has been lost.  The 'include' function is at line 427
in the file it is in -- not 0.

Furthermore, it appears the line numbers may be based on the "reconstituted
source" rather than the original source.  Either way -- this is why I want
to be able to turn on storing of the definition from the beginning of the
login session.

If I add shopt -s extdebug at the beginning of /etc/profile, the correct
filename and line number are stored and displayed with '-F'.

As for storing the original source -- for the reasons above.  As a
safety to allow the debugger to operate under adverse conditions. 
Storing all of the
scripts in my bin and lib dirs (including duplicates) would cost about 10MB.
Cutting to ones with extensions cuts that to a bit over 100K.  Compared
to the
memory on my machine, that's trivial if it gives access to the source
under the adverse conditions listed above.

But 1st, you need to realize that the BASH variables are just as "lost"
as bashdb.  If source-file and line numbers of definitions are turned on
from the beginning of a login session, then no matter what function is
called, it will be known to bash -- and, thus, bashdb -- which can at least
try to read in the original source.

I.e. doc issues, and source issues aside, the real source+line numbers for
defined functions need to be kept from the start -- then a debugger has a
chance of finding things.  As it stands right now, not even bash knows
where things came from 'environment'?  functions always at line 0?
Naw...I don't think so.


Apart from source formatting, it would be infrequent that the source file
and line shown in "-F", would not be accessible -- at least the debugger
would
have a chance of using that info to display what is happening.

Thanks!

Linda





>  The declare -F stuff is not,
> but I don't see that as generally useful outside the debugger.
>
>   
>> Also, the desire to retain the original source format of code is another
>> "in bash" issue.  Perhaps it could be tied or related to the turning on
>> of function definition locations.
>>     
> The debugger goes back to the original source file to find the function
> definitions, doesn't it? It's wasteful and not particularly useful to have
> the function definition text stored internally when you can regenerate an
> equivalent form from the compiled function definition.
>
>