Re: Second trap invocation is ignored?
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, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Second trap invocation is ignored?
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) Other than this minor question, your explanation makes total sense. Thanks Chet. - Scott
Re: Second trap invocation is ignored?
On Sun, Apr 05, 2015 at 09:39:50AM -0700, Scott Bronson wrote: 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). 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 As soon as I try your source trick, things start to break down: imadev:~$ echo 'trap echo $1 DEBUG' foo second imadev:~$ source ./foo one second imadev:~$ echo hi second hi But if I clear the DEBUG trap first, then it starts to work: imadev:~$ trap - DEBUG second imadev:~$ echo hi hi imadev:~$ source ./foo one imadev:~$ echo hi one hi So, if there is a bug here, it's got something to do with setting traps in a sourced file, when that type of trap is already set. (Also, I didn't try with any other traps. Maybe it's specific to DEBUG.)
Re: Second trap invocation is ignored?
Read about set -T in the manual. Also, you have an error in your trap definition. The $1 inside ... will expand at *definition* time, not when the trap is executed. See: dualbus@yaqui ~/t % cat script echo ' trap echo $1 DEBUG ' ./trapcmd source ./trapcmd first source ./trapcmd second dualbus@yaqui ~/t % bash script first dualbus@yaqui ~/t % bash -T script first first dualbus@yaqui ~/t % cat script2 echo ' trap echo \$1 DEBUG ' ./trapcmd source ./trapcmd first source ./trapcmd second dualbus@yaqui ~/t % bash script2 dualbus@yaqui ~/t % bash -T script2 second -- Eduardo Bustamante https://dualbus.me/
Re: Second trap invocation is ignored?
On Mon, Apr 06, 2015 at 10:31:49AM -0500, Eduardo A. Bustamante López wrote: dualbus@yaqui ~ % bash -c 'trap echo bar DEBUG; source /dev/fd/0; :' 'trap echo foo DEBUG; :' bar foo bar Here, the first `bar' is executed before `source'. Then, we enter a new `scope', or whatever this is called. Then, there's `foo', due to the `:' called inside the sourced script. After we `return' from the sourced script, `bar' is written, before the `:' from the main script (the -c one). So, essentially, we have two DEBUG traps set at the same time, living in different scopes. (DEBUG, RETURN and ERR are the only ones special here, I think). I'd be fine with that, but then why does source ./foo create a DEBUG trap at the global scope the *first* time?
Re: Second trap invocation is ignored?
On Mon, Apr 06, 2015 at 10:04:12AM -0500, Eduardo A. Bustamante López wrote: 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, it'll not work as you want. It doesn't matter whether the old DEBUG trap runs before or after the new trap is defined. It's not about the output. That's a red herring. The problem is the second trap definition *does not stick*. imadev:~$ echo 'trap : one DEBUG' foo imadev:~$ echo 'trap : two DEBUG' bar imadev:~$ trap - DEBUG imadev:~$ source ./foo imadev:~$ source ./bar imadev:~$ trap -p DEBUG trap -- ': one' DEBUG It's still got the first definition, not the second one.
Re: Second trap invocation is ignored?
On Mon, Apr 6, 2015 at 5:38 AM, Greg Wooledge wool...@eeg.ccf.org 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 in my bug report. That doesn't really help my case though. Well, I could have my script echo a trap command to the console and ask the user to re-type it. :) As soon as I try your source trick, things start to break down: imadev:~$ echo 'trap echo $1 DEBUG' foo second imadev:~$ source ./foo one second imadev:~$ echo hi second hi But if I clear the DEBUG trap first, then it starts to work: imadev:~$ trap - DEBUG second imadev:~$ echo hi hi imadev:~$ source ./foo one imadev:~$ echo hi one hi Agreed. And clearing the debug trap from a script doesn't work: ~$ echo 'trap echo $1 DEBUG' foo ~$ echo 'trap - DEBUG' unfoo ~$ source foo one one one ~$ source foo two one one one ~$ source unfoo one one one ~$ source foo three one one one ~$ $(cat unfoo) one ~$ ~$ source foo four four four So, if there is a bug here, it's got something to do with setting traps in a sourced file, when that type of trap is already set. (Also, I didn't try with any other traps. Maybe it's specific to DEBUG.) Yep. I haven't tried with any traps other than DEBUG, just because that's the only trap my script needs. If the maintainers would like more information about affected traps, I'm happy to investigate. - Scott
Re: Second trap invocation is ignored?
On Mon, Apr 6, 2015 at 8:04 AM, Eduardo A. Bustamante López dual...@gmail.com 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, it'll not work as you want. True, but that doesn't explain why the first sourced invocation succeeds, but all invocations thereafter fail. Is there a reason for this behavior? Why should a call to trap succeed or fail depending on whether the trap is already set or not? If that's expected behavior, I would certainly like to document it! Thanks, - Scott
Re: Second trap invocation is ignored?
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, it'll not work as you want. -- Eduardo Bustamante https://dualbus.me/
Re: Second trap invocation is ignored?
On Mon, Apr 6, 2015 at 6:10 AM, Eduardo A. Bustamante López dual...@gmail.com 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: I'm not quite sure if sourcing a file is supposed to share ALL script contexts, or be more like calling a function. If the former, -T would never be required, and if the latter, -T would always be required. Just curious, is this documented anywhere?) Also, you have an error in your trap definition. The $1 inside ... will expand at *definition* time, not when the trap is executed. See: But I want it to expand at definition time. That makes it easy to see if the trap call worked or not. Here's the bug with explicit expansion: echo trap 'echo first' DEBUG script1 echo trap 'echo second' DEBUG script2 . ./script1 . ./script2 I would expect the trap calls in script1 and script2 to behave identically. Instead, script1's trap is set, but script2's trap is ignored. Thanks for the reply. - Scott
