'trap' compliency?

[Denys Vlasenko]

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