Re: declare -F incorrect line number

2022-10-08 Thread Chet Ramey
On 10/2/22 4:51 AM, Daniel Castro wrote: Bash Version: 5.0 Patch Level: 17 Release Status: release Description: declare -F yields the wrong line number for a function that has nested functions declared within. Instead it gives the line number of the last nested f

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

2022-10-08 Thread Cynthia Coan
Hi Koichi, > (This is just a side note about `local -' but unrelated to the main > discussion): I didn't mention it because I thought `set -e' is merely > an example to demonstrate the behavior of `defer', but if the handling > of `set -e' is one of the main motivations for requesting `defer', I

Re: [PATCH] Fix foreground dead jobs in trap handlers reported like background ones in `jobs'

2022-10-08 Thread Koichi Murase
Thank you for your reply and sorry for the late reply. 2022年10月4日(火) 0:56 Chet Ramey : > > I expect the same behavior of `f1' and `f2' as far as there are no > > background jobs. > > Why? f2 calls `jobs', and so requests information in a particular format, > which may or may not be the same format

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

2022-10-08 Thread Koichi Murase
Hi Cynthia, thank you for your reply. 2022年10月8日(土) 17:26 Cynthia Coan : > > 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

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

2022-10-08 Thread Oğuz
8 Ekim 2022 Cumartesi tarihinde Cynthia Coan yazdı: > > [...] I think > use cases outside of cleanup are relatively sparse, [...] There. There already are several ways to do cleanup on exit/return using existing features, why add one more? > [...] With your syntax you still have to be aware of

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

2022-10-08 Thread Cynthia Coan
Hi Koichi, > 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 > func

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

2022-10-08 Thread Koichi Murase
Hi Lawrence, 2022年10月8日(土) 16:04 Lawrence Velázquez : > On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote: > > [...]. One thing to note is that the RETURN trap > > should be cleaned up inside the RETURN trap itself by running `trap - > > RETURN', or otherwise the RETURN trap is erroneously cons

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

2022-10-08 Thread Koichi Murase
Let me update the example implementation of ``defer''. I think this is more readable: function defer { local trap eval "trap=($(trap -p RETURN))" trap -- " if [[ \$FUNCNAME != defer ]]; then trap - RETURN $1 ${trap[2]-} fi" RETURN } declare -ft defer I also tested

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

2022-10-08 Thread Koichi Murase
Hi Cynthia, 2022年10月8日(土) 15:56 Cynthia Coan : > 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 h

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

2022-10-08 Thread Lawrence Velázquez
On Sat, Oct 8, 2022, at 2:11 AM, Koichi Murase wrote: > 2022年10月8日(土) 12:04 Cynthia Coan : >> [...] >> >> Otherwise, I think we can perhaps reword this into two smaller >> features: "function local trap signals", > > The existing RETURN trap is exactly the trap that can be used to clean > up resour

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

2022-10-08 Thread 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 forwar