Re: Second trap invocation is ignored?

[Chet Ramey]

On 4/10/15 5:27 PM, Scott Bronson wrote:
> On Fri, Apr 10, 2015 at 8:16 AM, Chet Ramey <chet.ramey@case.edu> wrote:
>> On 4/6/15 11:58 AM, Greg Wooledge wrote:
>>> I'd be fine with that, but then why does "source ./foo" create a DEBUG
>>> trap at the global scope the *first* time?
>>
>> Because there's nothing to save and restore.
> 
> Just curious: why not restore the state of emptiness that
> existed before?  Why treat these two states differently?
> (presence of trap vs. absence of trap)

Two reasons: it worked better with the common case of sourcing a file that
provided a trap definition, and it paralleled how the -T option worked
with shell functions.

It's a bug that a DEBUG trap definition in a sourced file gets discarded
when an existing old value is restored.  That's inconsistent with how
source is supposed to work, since the shell doesn't have local trap
scoping.

Chet

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