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

[L A Walsh]

On 3/6/2019 7:18 AM, Chet Ramey wrote:
>> 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.
>>     
>
> If you don't want functions to appear in the environment, don't put them
> in the environment. Bash is reporting accurately where it read the
> definition for `addnums'.
>   
1) Where is it documented that if you export a function, the original
source location is thrown away by bash?  That is not expected behavior
from reading the bash manpage.  YOU may expect it, I understand and I
understand what you mean when you talk about a function that has been
read from disk that has the '-x' bit set, becomes an 'exported' function
that loses its debug information.

    Fine.  How is it that throwing away debug for exported functions was
considered "desirable"?  I don't recall that ever being mentioned on this
list, nor in the manpages.

2). Ok, so it currently gets lost.  Why shouldn't it be fixed?
Either always keep around source+line or just when some option is set.
To minimize impact, I'd probably store all of them in 1 place so I can
do text compression and encode in some storeable format -- at worse BASE64.
>
>   
>>> 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.
>>     
>
> You exported it, putting it into the environment, losing the file and line
> information.  
>   
And the fact that it is lost is desired, designed behavior or an oversite?
And is documented where?  Both semi pointless when the real question is how
to fix it (again, likely with some option, only).  NOTE: unlike the current
implementation, files should be stored by absolute path, since if the
script changes to another directory, we still want the path to be valid.
>   
>> 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.
>>     
>
> This is gibberish.
>   
Not entirely.  Certainly you would agree the function, when initially loaded
into bash came from some file and line number.  I was attempting humor
thinking
about an alternative where bash mysteriously appears in the environment from
some unknown origin.  Ok, so it's not funny to you.  Fine be a hard
audience,
see if you're happy!  ;~)

>   
>> 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.  
>>     
>
> This is nonsense, unless you want to pass this hypothetical original
> text through the environment as well.  
>   
Uh...yeah, no matter where it is passed, if it had the source, it might
present
it for purposes of single stepping through it, but that would be a heavier
weight solution than just passing in the source+line.
>   
>> 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.
>>     
>
> OK, then don't use the environment to pass functions you want to step
> through. If you want to do that, accept that you have deliberately
> defeated the bashdb feature you want to use.
>   
---
    Only deliberately if I *knew* that bash threw away debug info on export.
As it isn't documented anywhere, I'd suggest that was unlikely.  Instead,
I copied that function to an external file in the same directory (via an
absolute path), so that when I needed to step through it, I could source
it again.  Not very elegant or efficient, but it is shell.

Thanks!