ksh: Ctrl+C in an exec'd interactive shell is buggy in some contexts
This bug is a regression introduced in commit 41ebb55a. From my testing it can be reproduced on Linux but not FreeBSD or Solaris. When Ctrl+C is used in an interactive shell to send SIGINT
, one of the following can happen:
- An erroneous ‘Interrupt’ message is printed after stopping the
read
builtin in a script. Reproducer:
$ exec arch/*/bin/ksh
$ cat ./reproducer.sh
#!/bin/sh
read foo
$ ./reproducer.sh
^C$ <Enter>
[1] + Interrupt ../reproducer.sh
- Ctrl+C fails to stop
/bin/package make
. Reproducer:
$ exec arch/*/bin/ksh
$ mv arch arch.old
$ bin/package make
# Press Ctrl+C multiple times
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 21
After fixing my screw-up with the following patch, I can no longer reproduce the problem. @JohnoKing and @hyenias, can you confirm?
My process works fine, no need to change it on my account. I also like being able to read the diff in the discussion, even if my C is +20 years old and I don’t necessarily understand them. 😃
I like seeing the colored diffs within the comments. More often than not, I look at the contents on screen than attempt to apply them to my git repo. Now, that I have been trained how to snip the diff contents and create a remote file.patch; I am good-to-go. I like seeing all the colors when I view the .patch file in my text editor. I bet, in time, github.com will enhance the web interface to allow us to download the embedded source text as diff or a file.
Confirmed. All works now.
I can no longer reproduce the bug after applying that patch.