Re: signals ignored in a subshell

From	Oğuz <oguzismailuysal@gmail.com>
Newsgroups	gnu.bash.bug
Subject	Re: signals ignored in a subshell
Date	2020-04-06 15:06 +0300
Message-ID	<mailman.241.1586174767.2644.bug-bash@gnu.org> (permalink)
References	(3 earlier) <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> <CAH7i3Lo_vDKahPLAgCvuPXw-TbgfgKt9OeJw-Ki2nja+ew-nDg@mail.gmail.com>

Show all headers | View raw

Or, is it that when job controls are enabled each synchronous command is
run in its own process group and SIGINT is not sent to the shell at all?

6 Nisan 2020 Pazartesi tarihinde Oğuz <oguzismailuysal@gmail.com> yazdı:

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

-- 
Oğuz

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

Thread

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

csiph-web