> 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 <oguzismailuy...@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
