Re: Bug: Bash forgets sourcefile and linenumber of read-in functions

[L A Walsh]

On 3/4/2019 4:53 PM, Chet Ramey wrote:
> On 3/4/19 6:44 PM, L A Walsh wrote:
>
>   
>>> What does `trace' mean here?
>>>       
>> ---
>> from the manpage:
>>     "output generated when set -x is  enabled"
>>     
>
> OK. We've only been talking about function tracing to this point. There
> are several uses for the word, depending on context.
>   
---
    ???  Who's this 'we' kimosami?  :-)
    Ok, so function tracing enables the functions inheriting various
traps, but doesn't explicitly enable the "-x" functionality...is that
right?

I've specifically been talking about information that is printed out
from the value of PS4.  Wouldn't that exclude function and error
tracing (unless -x is automatically turned on when you turn on
function and/or error tracing)?


> OK, doing that doesn't reveal any problem. If you add
>       shopt -s extdebug; declare -F addnums
> to prog.sh, it prints
>
> addnums 0 environment
>   
That it prints 'environment' and '0' are issues as the manpage says:

   the -F option to declare or typeset
   will list the function names only (and optionally the source file
   and line number, if the extdebug shell option is enabled).

Following those instructions, I enabled the extdebug option before
the function was defined -- I set a null DEBUG handler just so
if bash called a DEBUG handler, then I'd make sure to return 0 so
nothing would be skipped.  And...then I find out that 'extdebug'
also starts the bash debugger.

Except that .... the bash debugger gets lost on files that don't
have a real source file name. Environment is not the name of the file
containing the function -- it is a nebulous, ephemeral area of a
process -- but it certainly is not the repository for source files
that configure bash's behavior.

> which is correct: the shell read the definition of addnums from the
> environment,
Except... how did it get into the environment/  It wasn't there when
bash started.  Bash created a COPY there -- but the COPY is not
a SOURCE file.

There's no way you can convincingly say that you believe the source came
out of nothing into bashes environment, so we'll hopefully avoid
that topic as well as bash "being the way it is" due to being kidnapped
by space aliens.

Of course the debugger could recover here if bash had kept the
actual source lines of the function as they were read in, but, as you
mention, it would take more memory.  So ... if you remember,
this started out in a previous thread with my reporting that turning
on file+line functions with shopt -s extdebug gave incidental errors
in bashdb -- which you said was started in response to setting extdebug.

But bashdb doesn't work reliably without, at least being able to find
the source.  So the subject of that thread changed to:

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

Which lead to your assertion that it did, except neither I nor the
debugger can accept 'environment line 0' as a useful source file + line
number at which we can find the definition of the function we want to
step through.

So in terms of what is needed, not keeping the debug symbols for the
functions around (for bash, that's source file+line number at the least),
it makes the functions only slightly easier to debug than a stripped
binary.  From those terms it is a design "deficit" (or flaw)...which
still makes it something that doesn't meet the requirements (nevermind
that software engineers never know about requirements until after the
product is released) that needs a solution or fix.

In terms of documented behavior -- it's also "flawed", in that
bash doesn't achieve the behavior it is documented to have (and its
cheating to "fix" the documents to match the flawed behavior like
big companies regularly do (MS, Google, Adobe, etc...).

I'm not saying that they have to be stored by default either -- I was
willing to go and turn on options that I thought should store them --
it is just that they didn't work.  :-(

>  and the environment doesn't have line numbers, per se.
>   
You might think that, except why does single stepping through it increment
the line number?  ;^)

-l

This reminds me of another issue I'm dealing with: google changing the
definition of "filtering" to exclude keeping track of #copies going
through the same email box and *deleting* duplicates[*sic] being routed
to a a single email collection address before being passed on to the
end user's computer.  So even though they supposedly allow you to turn
off filtering, that doesn't prevent them from deleting emails before
you get them.

* - they aren't really duplicates as they have different headers and
delivery destinations.