On Monday 21 September 2009 23:55, Cristian Ionescu-Idbohrn wrote: > On Mon, 21 Sep 2009, Denys Vlasenko wrote: > > > On Monday 21 September 2009 12:59, Cristian Ionescu-Idbohrn wrote: > > > http://www.opengroup.org/onlinepubs/009695399/utilities/trap.html > > > > > > ,---- > > > | The shell shall format the output, including the proper use of > > > | quoting, so that it is suitable for reinput to the shell as commands > > > | that achieve the same trapping results. For example: > > > | > > > | save_traps=$(trap) > > > | ... > > > | eval "$save_traps" > > > `---- > > > > > > ash resets all traps when running trap in a subshell, so the > > > save_traps variable will be empty. bash does the right thing. > > > > Holy sh*t. What is the "right thing in this case, eh? > > Sorry for not being clear.
No, I understood you. I am just saying that making this happen requires making code which actually MUST LIE. :( > This is what I mean: > ... > save_traps=$(trap) > echo "--saved-traps" > echo "$save_traps" > > I want to be able to store the list of traps in a variable. Sure. But, in $(xxx) traps are not set. Honest. Thus, one needs "trap" command to lie (!) in order to achieve what one wants. This does not feel right: consider: trap "echo hello" SIGWINCH echo `. unsuspecting_shell_script.sh` Whoever tries to use "trap" inside unsuspecting_shell_script.sh code would get bogus results - it'll say that SIGWINCH is trapped but it is not! And it would be hard to express in C code: basically, on entry to $() or `` (and _only_ in this case), traps should be unset, but should not be forgotten - "trap" cmd should still show these "ghost" traps. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
