direnv: read followed by ctrl+c terminates bash shell-session [bash 5.1 fixed]

Describe the bug

With direnv hook enabled in a shell-session, calling read ans followed by a ctrl+c kills both read and current shell-session (occurs on both Mac and Archlinux systems)

Further testing on Archlinux:

root user was unable to reproduce
all other users dropped out (even with 0 modifications to .bashrc, .profile, ect

Exit code of ctrl+c fromread ans (on archlinux) yields 130, and is followed through to shell.

To Reproduce Steps to reproduce the behavior:

in bash shell-session: eval "$(direnv hook bash)"
send key sequence <ctrl+c>
notice current shell-session is terminated

Expected behavior bash shell-session should not terminate.

Environment

OS: mac os, archlinux
Shell: “mac” bash 3, gnu bash 5
Direnv version 2.21.1

Additional context Ran the test as root on archlinux; it did not terminate my shell-session.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 4
Comments: 18 (7 by maintainers)

Commits related to this issue

Work around problem with direnv prompt hooks See: https://github.com/direnv/direnv/issues/627 Apparently fixed in bash 5.1 If I hit ^C in uselect, this would exit the shell. This was driving me nut... — committed to sdt/.dotfiles by sdt 3 years ago
[bash] move direnv config to extra file Also attempt workaround https://github.com/direnv/direnv/issues/627 — committed to hmenke/netsettings by hmenke 2 years ago

Most upvoted comments

I’d rather find a solution that works for both scenarios. Personally I am never hitting that issue but encounter the cancel one quite a lot.

Current workaround:

Replace eval "$(direnv hook bash)" with

_direnv_hook() {
  local previous_exit_status=$?;
  eval "$(direnv export bash)";
  return $previous_exit_status;
};
if ! [[ "${PROMPT_COMMAND:-}" =~ _direnv_hook ]]; then
  PROMPT_COMMAND="_direnv_hook${PROMPT_COMMAND:+;$PROMPT_COMMAND}"
fi

zimbatm on May 27, 2020

I’ve reported the problem yesterday before finding this issue. https://savannah.gnu.org/support/index.php?110335

roberth on Oct 21, 2020

Chet Ramey has released bash 5.1 which is supposed to fix this issue.

roberth on Dec 22, 2020

Yep, it’s a bash bug. Not sure if it has been reported yet.

zimbatm on Jul 30, 2020