Re: feature request: new builtin `defer`, scope delayed eval
On Sat, Oct 8, 2022, 12:03 Oğuz wrote: > 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 what's > > in that trap [...] > > > > Not really. If, for some reason, I didn't know what's in that trap and were > super paranoiac about it, I could do > > oldaction=$(trap -P EXIT) > trap 'eval "$oldaction"; bar' EXIT > > I've never been in such a situation though. > there is, run code addment / management , for trap code > > Don't get me wrong, I just like it when new features align with the old > ones and work together nicely. > > > -- > Oğuz >
Re: pop_var_context msg when eval code with errexit set
On 10/12/22 12:58 AM, Xavier Delaruelle wrote:
Bash Version: 5.2
Patch Level: 2
Release Status: release
Description:
Starting version 5.2, when evaluating bash code (with eval builtin
command) with 'errexit' option set, a pop_var_context message appears
if the evaluating code leads to an error:
test_script: line 5: pop_var_context: head of shell_variables not
a function context
See the reproducer test code in Repat-By section.
I work on a project that provides a bash function in user
environment (https://modules.sourceforge.net/). This function produces
bash shell code that is evaluated in current shell session to update
it. When
users run their script in 'errexit' mode, I would expect not to obtain
this pop_var_context message, like in previous bash versions.
I first detected this issue on FreeBSD 13-1, but I have also
reproduced it on a Linux environment.
Repeat-By:
Script to reproduce the issue:
```test_script
myfunc() {
eval "test 0 = 1;"
}
cmd="myfunc"
eval "$cmd"
```
Then run this test script with 'errexit' option set:
$ ./bash -e test_script
test_script: line 5: pop_var_context: head of shell_variables not
a function context
It's an internal message warning that something might be wrong. We'll see
if something is.
--
``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/
Pending signal in EXIT trap causes pattern matching to fail
gmatch in lib/glob/sm_loop.c returns FNM_NOMATCH when a signal is pending. This can cause spurious pattern matching failures if a SIGPIPE is received while executing the EXIT trap: $ cat trap.sh trap 'set -x; echo trap; case a in *) echo match >&2;; esac; echo done >&2' EXIT while :; do :; done $ bash trap.sh | : ^C++ echo trap trap.sh: line 1: echo: write error: Broken pipe ++ case a in ++ echo done done -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Pending signal in EXIT trap causes pattern matching to fail
On 10/12/22 11:23 AM, Andreas Schwab wrote: gmatch in lib/glob/sm_loop.c returns FNM_NOMATCH when a signal is pending. This can cause spurious pattern matching failures if a SIGPIPE is received while executing the EXIT trap: OK. An interrupt or a terminating signal, yes. Since gmatch and extmatch can call each other recursively, this is a way to deal with the problem described in https://lists.gnu.org/archive/html/bug-bash/2021-07/msg00065.html by letting higher layers handle it. But that's not really the issue right here. The question is whether the shell should process additional terminating signals while it's running the exit trap from the terminating signal handler. -- ``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/
