Re: bracket needs to be escaped in variable substitution?
On 10/6/22 6:04 PM, Antoine wrote: Issue is not reproduced when using a variable as pattern, and it's not related the space character in the pattern: Thanks for the report. This will be fixed in the next devel branch push. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: extglob can be erroneously enabled in bash-5.2 through comsub nesting
On 10/6/22 7:58 PM, Kerin Millar wrote: Thanks for the report. I've attached the patch I applied to fix this. Thanks for the patch. It is probably sufficient for the downstream bug report to be closed. Unfortunately, it remains the case that the >=5.2-rc3 parser is buggy. Thanks for the additional test. I'll take a look. It's unlikely that users will encounter this scenario. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: feature request: new builtin `defer`, scope delayed eval
The Go programming language has a "defer" statement which is used considerably for exactly this purpose. So we know that it's useful in practice. The question remains what is a good way to introduce it into Bash. As others have noted, there is already a "trap" with similar functionality. I'm not familiar with it, but it seems that it does not have "signal" choices that cover the the situation(s) we want "defer" to be triggered by. However, that seems to be a straightforward extension. More important is "safely appending to a trap can be filled with holes". Why don't we allow a trap to be a sequence of strings, and define a new option to "trap" that prepends the argument string to the sequence? (Go specifies that "defer" actions are executed in reverse order from the execution of the "defer" statements that establishd them.) This approach seems to have the functionality we want while being a small extension of an existing, similar mechanism. Dale
Re: feature request: new builtin `defer`, scope delayed eval
I definitely got the inspiration of the name from the Go programming language. There are several other languages who use similar concepts when dealing with cleanup where something like an RAII pattern to free resources. It sounds like we're leaning towards trap, over a new built-in which I think is fair given its similarities. The question I think we have to ask is "are we okay extending `trap` in these two ways" you mentioned, or are we perhaps making `trap` into something it shouldn't be? Another way to put it might be: are we using `trap`, or abusing it. Are these changes to `trap` generally usable, are they breaking in any way, or are they creating potential places for misuse that it wouldn't be worth adding these features to an existing interface? I can't think of any off the top of my head, but I'll give it some thought. Otherwise, I think we can perhaps reword this into two smaller features: "function local trap signals", and "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). - Cynthia On Fri, Oct 7, 2022 at 7:49 PM Dale R. Worley wrote: > > The Go programming language has a "defer" statement which is used > considerably for exactly this purpose. So we know that it's useful in > practice. The question remains what is a good way to introduce it into > Bash. > > As others have noted, there is already a "trap" with similar > functionality. I'm not familiar with it, but it seems that it does not > have "signal" choices that cover the the situation(s) we want "defer" to > be triggered by. However, that seems to be a straightforward extension. > > More important is "safely appending to a trap can be filled with holes". > Why don't we allow a trap to be a sequence of strings, and define a new > option to "trap" that prepends the argument string to the sequence? (Go > specifies that "defer" actions are executed in reverse order from the > execution of the "defer" statements that establishd them.) > > This approach seems to have the functionality we want while being a > small extension of an existing, similar mechanism. > > Dale
Re: feature request: new builtin `defer`, scope delayed eval
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
Re: feature request: new builtin `defer`, scope delayed eval
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 resources local to functions and is already ``function-local''
unless the user changes its behavior by setting `declare -ft', `set
-T', or `shopt -s extdebug'. 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 considered by
Bash to be set for the caller function.
> and "options to safely
> append/prepend to a trap" (for some definition of 'safe', perhaps this
> just means separating by ';'?
Currently, there is no way to register multiple handlers to a trap in
a safe way, but if you can accept the approach by `;' or newline, you
can just do it by getting the current trap string with `trap -p
RETURN' and then overwrite the trap with the adjusted trap string. If
you don't want to write such a code every time, you can write a shell
function to perform that. In that case, be careful that the function
needs to be marked with the trace attribute by ``declare -ft
''. Also, the RETURN trap needs to be suppressed for
such a function itself. I haven't really tested it but something like
this should work as you expect:
function defer {
local command=$1 trap
eval "trap=($(trap -p RETURN))"
if [[ $trap ]]; then
trap[2]=$command$'\n'${trap[2]}
else
trap=(trap -- "$command" RETURN)
fi
trap[2]='if [[ $FUNCNAME != defer ]]; then '${trap[2]}$'\ntrap - RETURN\nfi'
"${trap[@]}"
}
declare -ft defer
The above `defer' function effectively "eval"s the first argument
through `trap', so you need to specify in the following way:
defer 'rm -r "${tmp_dir}"'
defer 'set +e'
defer 'set +o pipefail'
Another thing to note is that the RETURN trap will be skipped when
Bash receives SIGINT, so if you want to properly perform the clean up
even when your Bash program receives SIGINT, you need to additionally
set the SIGINT handler in a proper way.
--
Koichi
Re: feature request: new builtin `defer`, scope delayed eval
Hi Koichi,
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 also have in
the past written several helpers for safely appending to a trap (yours
in particular can mess up with certain quoting rules, but is nothing a
quick sed can't fix). The latest example for this was effectively a
joke project I did (so not really fully complete, expect bugs, etc.),
but also shows more complex forms I've done, in the past:
https://raw.githubusercontent.com/Mythra/typeish/trunk/pkg/trap.sh ,
https://raw.githubusercontent.com/Mythra/typeish/trunk/pkg/defer.sh .
It was writing things of this nature in enough projects that actually
brought forth this proposal.
I don't see any particular criticisms about either `defer` as a
built-in, or adding functionality to `trap` outlined in particular.
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" (mostly talking about the want to colocate cleanup with
creation, rather than splitting it into another function for easier
readability when cleanup actions are very multi-stepped).
As such I can only guess that either:
- you were trying to inform the list that it is possible. which I
appreciate! I know my original email left only a simple example, and
didn't delve into the other areas we now are talking about like traps.
- or that because it is possible means we should not work at
improving this functionality at all. To which I would mention the fact
that we've added things like `local` which could also be implemented
with `RETURN` traps, I do not think we should use it as a blocker as a
reason itself, personally.
Thanks,
Cynthia
On Sat, Oct 8, 2022 at 12: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 resources local to functions and is already ``function-local''
> unless the user changes its behavior by setting `declare -ft', `set
> -T', or `shopt -s extdebug'. 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 considered by
> Bash to be set for the caller function.
>
> > and "options to safely
> > append/prepend to a trap" (for some definition of 'safe', perhaps this
> > just means separating by ';'?
>
> Currently, there is no way to register multiple handlers to a trap in
> a safe way, but if you can accept the approach by `;' or newline, you
> can just do it by getting the current trap string with `trap -p
> RETURN' and then overwrite the trap with the adjusted trap string. If
> you don't want to write such a code every time, you can write a shell
> function to perform that. In that case, be careful that the function
> needs to be marked with the trace attribute by ``declare -ft
> ''. Also, the RETURN trap needs to be suppressed for
> such a function itself. I haven't really tested it but something like
> this should work as you expect:
>
> function defer {
> local command=$1 trap
> eval "trap=($(trap -p RETURN))"
> if [[ $trap ]]; then
> trap[2]=$command$'\n'${trap[2]}
> else
> trap=(trap -- "$command" RETURN)
> fi
> trap[2]='if [[ $FUNCNAME != defer ]]; then '${trap[2]}$'\ntrap - RETURN\nfi'
> "${trap[@]}"
> }
> declare -ft defer
>
> The above `defer' function effectively "eval"s the first argument
> through `trap', so you need to specify in the following way:
>
> defer 'rm -r "${tmp_dir}"'
> defer 'set +e'
> defer 'set +o pipefail'
>
> Another thing to note is that the RETURN trap will be skipped when
> Bash receives SIGINT, so if you want to properly perform the clean up
> even when your Bash program receives SIGINT, you need to additionally
> set the SIGINT handler in a proper way.
>
> --
> Koichi
