On Fri, Apr 10, 2015 at 8:16 AM, Chet Ramey 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 th
On Mon, Apr 6, 2015 at 8:04 AM, Eduardo A. Bustamante López
wrote:
> There is no bug. Simply, your expectations on when the DEBUG trap runs are
> wrong.
>
> The `script2' I provided ran with set -T is the closest you'll get to what you
> expect, but, since DEBUG runs *before* the source command, i
On Mon, Apr 6, 2015 at 5:38 AM, Greg Wooledge wrote:
> Without the source shenanigans, it works:
>
> imadev:~$ trap 'echo first' DEBUG
> imadev:~$ echo hi
> first
> hi
> imadev:~$ trap 'echo second' DEBUG
> first
> imadev:~$ echo hi
> second
> hi
Absolutely right, and I should have included that
On Mon, Apr 6, 2015 at 6:10 AM, Eduardo A. Bustamante López
wrote:
> Read about set -T in the manual.
Hi, I did, over and over. :) I didn't see anything about -T being
unnecessary the first time you set a trap from a sourced script, but
being required every time thereafter.
(quick parentheses:
Hi, I don't understand the behavior of the trap command...
echo '
trap "echo $1" DEBUG
' > ./trapcmd
source ./trapcmd first
source ./trapcmd second
I would expect the debug trap to now be 'echo second'.
However, it's still 'echo first' (full output below).
Why is the sec
