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?
In bash:
# trap 'echo Ho' SIGWINCH
# echo `trap; sh -c 'kill -WINCH $PPID'; sleep 1`
trap -- 'echo Ho' SIGWINCH
As you see, yes, "trap" in `xxx` reported that SIGWINCH has a handler,
but this handler was not called. So, "trap" actually lied.
And it gets worse! Now lets try this!
# echo `trap 'echo Ho' SIGWINCH; trap; sh -c 'kill -WINCH $PPID'; sleep 1`
trap -- 'echo Ho' SIGWINCH Ho
Wow. "trap" prints _exactly_ the_ same_ output_, but
the reality is different: now handler _is_ installed
and can be triggered! So, "trap" output is actually useless -
it does not give realiable information whether handler
is installed or not.
What to do now? Do we really want to implement such an idiosyncratic
"trap" behaviour? And if yes, what are the exact rules?
What to do with:
(trap)
trap&
{ trap; }&
trap | cat
...etc...
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
