bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chet Ramey
Subject: Re: Bug: Bash forgets sourcefile and linenumber of read-in functions
Date: Wed, 6 Mar 2019 10:18:55 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

On 3/5/19 12:13 AM, L A Walsh wrote:

>> 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.

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'.


>> 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.

> 
> 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.

> 
> 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.

> 
> 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.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]