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

[Cynthia Coan]

> I don't think this would be a feature worth the time to implement and
> the complexity it would introduce. Is there any other use case for this
> than cleaning up temporary files on function return?

Yeah! I think that's a fair point since it seems like we're landing on
traps being the way forward.  I think there may be some overlap
already here with the RETURN trap, I'm not seeing a huge
implementation burden yet, but I admittedly haven't played around with
this code much. Is there a particular area you're thinking this will
add a lot of weight to that RETURN doesn't add in some form? I think
use cases outside of cleanup are relatively sparse, which is part of
why originally I had proposed a builtin not adding to trap (something
more purpose-focused). I'll think about it though.

> This can be achieved by adding a new option to `trap' that causes it to
> print the action string for given condition. Let this option be named
> `-P', the user would do something like this to update a trap:

Yep! This is very similar to what I had in mind, however in a slightly
different form. With your syntax you still have to be aware of what's
in that trap (whether it ends with a semicolon or not, and things of
that nature). I'd really like to just be able to have a parameter
like:

`trap -P "foo" EXIT`
> Exit trap is now: "foo"
`trap -P "bar" EXIT`
> Exit trap is now: "foo;bar"

or whatever we end up using as a separator if it's not a semicolon.
That way as a user writing my script I never have to be aware of
what's already existing in a trap, I can always safely "add" my code,
without stomping over anybody else.

- Cynthia

On Fri, Oct 7, 2022 at 11:49 PM Oğuz İsmail Uysal
<oguzismailuysal@gmail.com> wrote:
>
> On 10/8/22 6:03 AM, Cynthia Coan wrote:
> > Otherwise, I think we can perhaps reword this into two smaller
> > features: "function local trap signals", and
> I don't think this would be a feature worth the time to implement and
> the complexity it would introduce. Is there any other use case for this
> than cleaning up temporary files on function return?
>
> > "options to safely append/prepend to a trap" (for some definition of
> > 'safe', perhaps this just means separating by ';'? Unsure if there's a
> > better way off the top of my head).
> This can be achieved by adding a new option to `trap' that causes it to
> print the action string for given condition. Let this option be named
> `-P', the user would do something like this to update a trap:
>
>      trap "foo;" EXIT
>      trap "$(trap -P EXIT)bar;" EXIT