signals ignored in a subshell
While waiting for read builtin to complete, bash executes signal handlers
in a subshell where signals are ignored. See below.
$ foo() { trap foo INT; read; }
$ set -x
$ foo
+ foo
+ trap foo INT
+ read
^C++ foo
++ trap foo INT
++ read
^C^C^C
(the only way to exit is tapping enter twice; i.e finishing both reads)
dash and mksh interrupts read and executes handler in CEE, zsh does
something similar to bash. Is this a bug or an undocumented feature?
--
Oğuz
Re: verbosity of DEBUG trap following edit-and-execute-command
On Fri, Apr 3, 2020 at 9:13 AM Chet Ramey wrote: > Since this is all wrapped up in existing shell features, there's no good > way to isolate the fc behavior. I've seen suggestions on here to disable > set -v while running the DEBUG trap unconditionally, like ksh93 does. I've found https://groups.google.com/d/topic/gnu.bash.bug/_oG51FIMDE0/discussion which suggests disabling [set -v] during the e-a-e-c but AFAICT doesn't talk about the DEBUG trap. Or are you saying that e-a-e-c is implemented using DEBUG? > What do you think? Should bash just disable set -v when running the DEBUG > trap? ISTM that yes set -v should be disabled during execution of the DEBUG trap. Separately, I've also never appreciated the echoing that happens post-e-a-e-c, but I do appreciate the echoing that !foo does when executing the last command with a prefix of "foo", so I guess I don't have a principled stand to take on that front :) Cheers, -a
Re: verbosity of DEBUG trap following edit-and-execute-command
On 4/2/20 12:50 PM, Ami Fischman wrote: > After the editor invoked by edit-and-execute-command exits, the > about-to-be-executed command (as edited by the editor) is echoed, but > seemingly > as if [set -v] was set, causing a command executed before the edited command > as > the result of a trap DEBUG to be echoed, as well. This is annoying for example > when using the DEBUG trap as a way to change colors as demonstrated in > https://nigeltao.github.io/blog/2018/colorful-text.html#shell-prompts OK. The editing commands are just a convenient way to execute the `fc -e -' command, starting with a file consisting of the command being edited. After editing, that file is executed like a shell script, and set -v is indeed temporarily enabled to show the edited commands being read. Since these edited commands are saved in the history list, we use the parser to honor the various history list config variables (command-oriented history, history ignoring, etc.) instead of just dumping the file before it gets executed. This is also how you get compound commands in the file echoed in their entirety before they're executed. So far so good. Since this is all wrapped up in existing shell features, there's no good way to isolate the fc behavior. I've seen suggestions on here to disable set -v while running the DEBUG trap unconditionally, like ksh93 does. What do you think? Should bash just disable set -v when running the DEBUG trap? 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: Obscure issue with process substitution since bash-5.0.016 upgrade
Thanks for your attention and the provided reduced patch. I can
confirm that, applied over bash-5.0.16, this solves my issue, both on
the test case as well as the bigger application from which it was
extracted.
Regards,
- Joan Bruguera
On Thu, 2 Apr 2020 at 23:20, Chet Ramey wrote:
>
> On 4/1/20 10:15 PM, Joan Bruguera Micó wrote:
> > I'm having a problem with a script that used to work, which I reduced
> > to the following test case:
> >
> > #!/bin/bash
> >
> > function docat() {
> > for x in 1 2 3 ; do true; done
> > cat "$@"
> > }
> >
> > for x in $(seq 25); do
> > docat <(echo a) <(echo a) <(echo a) <(echo a) <(echo a) <(echo a)
> > done
> >
> > Expected behaviour: A lot of lines with an "a" are printed
>
> Thanks for the report.
>
> Yes, this is a problem, as you discovered, with bash-5.0 patch 16. There is
> a better way to solve the problem that patch attempts to solve, and the
> enclosed patch to bash-5.0.16 does it.
>
> 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/
--
Joan Bruguera Micó - PGP key id: 88A7 A061 6B47 0CE1 EB4E D431 8744
44D1 21CE B72E
