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: Mon, 4 Mar 2019 19:53:03 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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.


> FWIW, the other day, I asked where 'function tracing' and 'error tracing'
> were defined (under the 'extdebug' option under 'shopt' in manpage). I'm
> still not sure what they mean (side info: I only know what execution tracing
> is. I don't know if it is the same or different than function or error
> tracing).

I posted the descriptions. They have to do with trap inheritance so the
debugger can single-step into and trace functions.

>> If I add these lines to prog.sh:
>>   
> _After_ lib.sh has been sourced (I have several functions defined and
> exported at login), run prog.sh.  sourcing lib.sh from prog.sh won't
> duplicate the problem.

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

which is correct: the shell read the definition of addnums from the
environment, and the environment doesn't have line numbers, per se.

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



reply via email to

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