On 4/10/15 5:27 PM, Scott Bronson wrote:
> On Fri, Apr 10, 2015 at 8:16 AM, Chet Ramey <chet.ra...@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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
