Hi Cynthia, 2022年10月8日(土) 15:56 Cynthia Coan <cynt...@coan.dev>: > I'm well aware that "defer"/"safe trap appending" can be implemented > today as it stands (see the original email in this chain, which links > to an example that I've used in a more reduced form).
I did notice your link to the Gist example, but I have to say that it misuses the RETURN trap. As I have written in the previous reply, the RETURN trap is already designed to be function-local so that it suits your use cases. However, the Gist version somehow disables the function-local nature of the RETURN trap by running `set -o functrace' and instead tries to implement the function-local behavior by itself. > I also have in > the past written several helpers for safely appending to a trap I also have implemented a wrapper (and the generalized mechanism) of the trap in my project [1], but I admit that this is overcomplicated for the general advice in the Bash mailing list (the entire code has about 1000 lines). But if you are interested in a larger framework, you might be interested in it. [1] https://github.com/akinomyoga/ble.sh/blob/a144ffa807b40baa2b58f558cdd3b22bca44d38e/src/util.hook.sh#L42-L61 > (yours > in particular can mess up with certain quoting rules, but is nothing a > quick sed can't fix). Could you describe it in more detail or could you provide an example of how this can mess up? For example, the quoting of the trap string in the output of `trap -p' is processed by "eval" in the second line of the function body. I currently don't see any other parts where the quoting is relevant. > I don't see any particular criticisms about either `defer` as a > built-in, or adding functionality to `trap` outlined in particular. I actually don't see sufficient reasons to add a builtin command or add `append/prepend' options to trap. The suggested `builtin' can be implemented by a short shell function of about 10 lines. If we finally conclude that the suggested `defer' is useful for the general Bash scripting, we can just include it in /examples/functions in the Bash source tree. As for the `append/prepend' option, I think they would be very useful, but I think it requires more careful and comprehensive discussions. For example, it is non-trivial to find well-defined semantics for the multiple separate trap handlers containing the commands that affect the control flow outside the trap (such as continue, return, break, etc.). It might also conflict with the existing idioms of trap/signal handlers that assume the single trap handler such as `trap - INT && kill -INT "$BASHPID"' for SIGINT. How to choose a single exit status of the DEBUG trap which would be used to determine the next action by Bash? etc. On the other hand, I think `trap -P' suggested by Oğuz can be safely added without conflicting existing behaviors, but this is more general and can be considered separately from the defer implementation. > In fact some of the things you mentioned you can do today, are also > outlined in the original email as things that can be "harder than they > need to be" (...). I agree the proper implementation of `defer' by the RETURN trap could be tricky (as described in "notes" in my previous reply), but it's definitely not as hard as you initially posted (one 12-line function vs 244-line defer.sh). -- Koichi
