Pressing Ctrl-C during any subshell evaluation terminates the s

[Daniel Farina]

Configuration Informatio:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux shrike 5.8.9-200.fc32.x86_64 #1 SMP Mon Sep 14 18:28:45
UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.0
Patch Level: 17
Release Status: release

Description:

Pressing Ctrl-C during any subshell evaluation terminates the shell.  I
noticed this when using direnv and emacs together: Ctrl-C would not cancel
a subprocess started by the shell, but would exit the entire shell.

Relaying this from: https://github.com/direnv/direnv/issues/627

Repeat-By:

Per https://github.com/direnv/direnv/issues/627#issuecomment-635611930

$ cat bash.rc
eval "$(direnv hook bash)"

$ bash --rcfile bash.rc
bash$ echo $PROMPT_COMMAND
_direnv_hook
bash$ $(sleep 10) # pressing ^C during those 10 seconds will terminate the
shell
^C
$ # inner shell terminated

Fix:

No known good fix.  It does seem zsh manages the situation normally without
much difference in approach. Direnv 2.20.0 does not have this bug, but it
also has deficits in how it traps signals.