signals ignored in a subshell

From	Oğuz <oguzismailuysal@gmail.com>
Newsgroups	gnu.bash.bug
Subject	signals ignored in a subshell
Date	2020-04-06 15:03 +0300
Message-ID	<mailman.240.1586174629.2644.bug-bash@gnu.org> (permalink)
References	(2 earlier) <CAH7i3Lr5TTK+N-qC39+nmSo7jjhzDvPux39N4i2MyP5LCnnv5w@mail.gmail.com> <16086.1586068489@jinx.noi.kre.to> <CAH7i3LrwPy9J9+8BPgvT+BGtv39nQJ2H-prxWXu7mHYZ8UjodQ@mail.gmail.com> <45c766ba-4489-bd7b-40c7-32fed37461f9@case.edu> <CAH7i3Lr5zBub6yObXkwV78E0Oyct-bAu2+D2hocpT8NNyBqHLg@mail.gmail.com>

Show all headers | View raw

>
> 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.
>

Okay, you're right, in posix mode the behavior is as expected. However I
still didn't get why job controls being enabled/disabled changes the way an
interactive shell handles signals in posix mode. Like

$ set -o posix
$
$ trap 'echo foo' INT
$
$ read
^Cfoo
$ sleep 5
^C
$
$ set +m
$
$ read
^Cfoo
$ sleep 5
^Cfoo

Is there a race condition here or does posix mandate this behavior for
built-in utilities?


-- 
Oğuz

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

signals ignored in a subshell Oğuz <oguzismailuysal@gmail.com> - 2020-04-06 15:03 +0300

csiph-web