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

[L A Walsh]

On 3/2/2019 2:29 PM, Chet Ramey wrote:
> On 3/1/19 11:11 PM, L A Walsh wrote:
>
>   
>> 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 you mean the function text, I don't think it's of general interest, and
> the debugger seems to manage to get along without it.
----
    No.  It doesn't.  It displays nothing which makes single stepping
through
any thing impossible.
>  You can get the file
> and line number where the function is defined when extdebug is on, even if
> you turn it on after the session has begun, and go from there.
>   
----
    Unfortunately, I can confirm that this DOES NOT WORK.

    Earlier you said you could get the sourcefile + line number from
BASH_SOURCE and BASH_LINENO(+LINENO).  I demonstrated that they printed
out completely unrelated values.

Just now, I tried turning on extdebug and using declare -F to print
the name of the source file and the line number:

This is the 1st few lines of a script that shows the problem:
#!/bin/bash -u
# vim=:SetNumberAndWidth
#set -x
hb=~law/bin (line#4)
hl=~law/bin/lib

if ! [[ $hb =~ $PATH ]]; then export PATH="$hb:$hl:$PATH"; fi

trap $((1)) DEBUG   (line#0)
shopt -s extdebug
declare -F include
include stdalias
-----------------------------------------------------------------------------
I run the above script and elide unrelated parts with "...":


> bash -x apply_patch
>~/.bash_env#8> [[ -n '' ]]
...[elided]
>~/.bash_env#22> _LOCAL_BASH_ENV_CALLED=1
>~/.bash_env#23> [[ -n '' ]]
>~/.bash_env#23> [[ -O /tmp/debug_local ]]
>apply_patch#4> hb=/home/law/bin  <<<---here is 1st executable line in script
>apply_patch#5> hl=/home/law/bin/lib
>apply_patch#7> [[ /home/law/bin =~
...
>apply_patch#9> trap 1 DEBUG       <<<--here is the trap debug statement
>apply_patch#10> shopt -s extdebug <<<-- turning on extdebug, as you say
works
>apply_patch#11> declare -F include  <<<--try to print sourcefile and
line where
                                          include is defined
include 0 environment               <<<< it prints the same wrong
information
                                    ------ as the BASH_SOURCE+LINENO
variables.

          include is NOT defined in a file called 'environment' and the 1st
line of a file is number '#1', not zero.
>apply_patch#12> include stdalias
>environment#0(include)> [[ -n stdalias ]]        The source + line numbers
                                                  from this point
through the
                                                  entire trace of
'include' is
                                                  wrong.
>environment#1(include)> local fnc=stdalias.shh
>environment#2(include)> [[ s == \/ ]]
>environment#6(include)> unset _FPATH

>   
>> If I add shopt -s extdebug at the beginning of /etc/profile, the correct
>> filename and line number are stored and displayed with '-F'.
>>     
>
> The filename and line number are always stored.
>   
----
    No.  They are not, as the above shows.  I try to display the
source+lineno
of the function definition and they are completely wrong.


> It's not of general enough interest to be worth the implementation cost.
> You could try modifying the parser and the input code to do it, if you
> were so inclined.
>   
---
    It is apparently that running a bash-debugger isn't worth the general
interest either since it has serious flaws that you and the bashdb author
are unaware of.  Without a correct sourcefile name and line number, storing
the source is pointless.  Like I said before, if the source and line number
were valid, it would still be possible in many cases (perhaps most cases)
to read the actual source, so storing the source would be a convenience.

     Storing the source may be necessary if single stepping doesn't
correspond
to the read-in source, if it does, then it's a luxury.


>> 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.
>>     
>
> The filename and line number are always stored. You can turn on extdebug
> any time you want to see them.
>   
----
    They are stored *wrong* as I showed in my previous email.  They are also
stored wrong such that turning on extdebug "late", won't display the correct
values. 


> bash-5.0$ declare -F xtitle
> xtitle
> bash-5.0$ shopt -s extdebug
> bash-5.0$ declare -F xtitle
> xtitle 59 /Users/chet/.bashrc
>   
----
    In my case they are defined before it ever gets to my .bashrc. in
my local-system bash includes that I have in /etc/local.  It is in
/etc/local/aliases.sh that I have 'include' defined.

    Also, I don't know that should make any difference, but when I login
to my system it is usually via 'ssh', not via a local GUI or console.