[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature request: new builtin `defer`, scope delayed eval

From: Koichi Murase
Subject: Re: feature request: new builtin `defer`, scope delayed eval
Date: Sat, 8 Oct 2022 16:48:58 +0900

Hi Cynthia,

2022年10月8日(土) 15:56 Cynthia Coan <cynthia@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.


> (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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]