Re: signals ignored in a subshell
5 Nisan 2020 Pazar tarihinde Robert Elz yazdı: > Date:Sun, 5 Apr 2020 05:06:56 +0300 > From:=?UTF-8?B?T8SfdXo=?= > Message-ID: w...@mail.gmail.com> > > | I was expecting it to work (i.e interrupt read again and call foo) > > Isn't that what it did? No, it ignored/blocked 2nd SIGINT . > But I see what you mean now, during the read that's called from the > trap execution call of foo, SIGINT is blocked - that most probably should > not happen, and it looks as if when the trap handler exits, the > original read is resumed, that certainly shouldn't happen. > > Exactly. In my opinion, read should behave the way wait does: fail upon a signal for which a trap is set, and return a non-zero value when handler returns. Don't really know how hard it would be to implement that though. I cloned and compiled bash's devel branch and tested this on it. It keeps printing a warning message upon every SIGINT (but doesn't ignore them). > Still, I don't believe that the way the function is written is a way > that you can expect will work necessarily. > > That function is a simplified version of a script posted here: https://stackoverflow.com/questions/61023171/bash-trap-sigint-multiple-times-doesnt-work > kre > > -- Oğuz
Re: verbosity of DEBUG trap following edit-and-execute-command
On 4/3/20 7:45 PM, Ami Fischman wrote: > 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? No. The emacs and vi mode editing commands are front ends to `fc'. POSIX requires this in various places: "For example, in vi editing mode, typing " v" is equivalent to: EDITOR=vi fc" fc executes commands from the file after editing. That file can hold an arbitrary series of commands, so it's useful to have the shell echo the commands as it reads them. You can't just dump a line at a time, since there might be compound commands, and dumping the contents of the file right after editing would be useless. So bash (and ksh93, mksh, zsh, but not any of the ash descendents) temporarily enable `set -v' while executing the file. There's nothing special about those commands, so if the DEBUG trap is set, the trap handler runs at the right time. There's nothing special about the DEBUG trap, either, so the verbose setting that's in effect causes echoing of those commands as they're read. Hence the discussion topic: should bash disable set -v when executing the DEBUG trap, should it do that just while running commands from a file while running `fc', or should it continue with its current behavior? 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: signals ignored in a subshell
On 4/4/20 1:32 AM, Oğuz wrote: > While waiting for read builtin to complete, bash executes signal handlers > in a subshell where signals are ignored. It doesn't, though. What bash-5.0 does is to effectively block SIGINT while executing a trap handler for SIGINT, since it doesn't let you run SIGINT trap handlers recursively. It's done that for at least 25 years, since I quit looking back when I got to bash-2.0. The devel branch version allows you to recursively execute a trap handler as many times as you like, or until you exceed your stack limit or hit the EVALNEST limit. I changed this in January, 2020. The devel versions will issue a warning. 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: signals ignored in a subshell
On 4/5/20 5:42 AM, Oğuz wrote: >> But I see what you mean now, during the read that's called from the >> trap execution call of foo, SIGINT is blocked - that most probably should >> not happen, and it looks as if when the trap handler exits, the >> original read is resumed, that certainly shouldn't happen. >> >> > Exactly. In my opinion, read should behave the way wait does: fail upon a > signal for which a trap is set, and return a non-zero value when handler > returns. Don't really know how hard it would be to implement that though. That's not how read is defined to behave. wait has special wording defining what happens when it receives a signal. Bash default mode behaves as I described previously -- trapping the signal and returning from the handler results in the read being restarted -- and posix mode will run the trap handler before returning from the `read' builtin. In bash-5.0, posix mode would return from the trap handler on the second SIGINT; that was a consequence of not allowing recursive signal handlers (which caused other problems, see https://lists.gnu.org/archive/html/bug-bash/2020-01/msg00014.html). The devel branch requires that the read be satisfied once, since interrupting it will now run the trap handler recursively. -- ``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: verbosity of DEBUG trap following edit-and-execute-command
On Sun, Apr 5, 2020 at 12:43 PM Chet Ramey wrote: > Hence the discussion topic: should bash disable set -v when executing > the DEBUG trap, should it do that just while running commands from a > file while running `fc', or should it continue with its current behavior? Thanks for clarifying the parameter space. For my purposes either of the first 2 options would work, but my only use of DEBUGhas been to muck with terminal state this way, so possibly users of DEBUG withless-visible side-effects would prefer it to stay as-is. Not sure if such usages exist orhow to trade-off the use-cases against each other. Of course, an alternative approach would be to enhance bash with a nativefacility for coloring emitted command-lines, to obviate the need for DEBUG in this context. Cheers, -a
