* [PATCH] Fix ctrl-c not working after process substitution @ 2019-04-09 18:34 ` Eric Freese 2019-04-10 8:42 ` Peter Stephenson 0 siblings, 1 reply; 2+ messages in thread From: Eric Freese @ 2019-04-09 18:34 UTC (permalink / raw) To: zsh-workers; +Cc: Eric Freese This is a potential fix for the ctrl-c problem reported in message 43148 You can reproduce the bug by running `zsh -f`, sourcing the following .zshrc, and (at the prompt) pressing ^T and then ^C: foo-request() { exec {FD}< <(echo foo) zle -F $FD foo-response } foo-response() { zle -F $1 } zle -N foo-request bindkey ^T foo-request After pressing ^T, ^C doesn't reset the prompt. I think this is because the forked <(echo foo) process calls entersubsh() without ESUB_ASYNC flag and so is set as the terminal's controlling process. My hypothesis is that the original process is never reset as the terminal's controlling process and thus the SIGINT signals are no longer sent to the original process. Adding ESUB_ASYNC flag to the entersubsh() call fixes the issue. I'm not sure though if there are some cases where we don't want to add the flag (e.g. when nullexec is 0)? --- Src/exec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Src/exec.c b/Src/exec.c index 79ef83c1e..6ac852112 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -4984,7 +4984,7 @@ getpipe(char *cmd, int nullexec) procsubstpid = pid; return pipes[!out]; } - entersubsh(ESUB_PGRP, NULL); + entersubsh(ESUB_ASYNC|ESUB_PGRP, NULL); redup(pipes[out], out); closem(FDT_UNUSED, 0); /* this closes pipes[!out] as well */ cmdpush(CS_CMDSUBST); -- 2.19.0 ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Fix ctrl-c not working after process substitution 2019-04-09 18:34 ` [PATCH] Fix ctrl-c not working after process substitution Eric Freese @ 2019-04-10 8:42 ` Peter Stephenson 0 siblings, 0 replies; 2+ messages in thread From: Peter Stephenson @ 2019-04-10 8:42 UTC (permalink / raw) To: zsh-workers On Tue, 2019-04-09 at 12:34 -0600, Eric Freese wrote: > This is a potential fix for the ctrl-c problem reported in message 43148 > > You can reproduce the bug by running `zsh -f`, sourcing the following > .zshrc, and (at the prompt) pressing ^T and then ^C: > > foo-request() { > exec {FD}< <(echo foo) > zle -F $FD foo-response > } > > foo-response() { > zle -F $1 > } > > zle -N foo-request > bindkey ^T foo-request > > After pressing ^T, ^C doesn't reset the prompt. > > I think this is because the forked <(echo foo) process calls > entersubsh() without ESUB_ASYNC flag and so is set as the terminal's > controlling process. My hypothesis is that the original process is never > reset as the terminal's controlling process and thus the SIGINT signals > are no longer sent to the original process. > > Adding ESUB_ASYNC flag to the entersubsh() call fixes the issue. I'm not > sure though if there are some cases where we don't want to add the flag > (e.g. when nullexec is 0)? Thanks, this makes a lot of sense. With nullexec it's still in a subprocess, so I think that's OK. Some of the other similar functions use ESUB_ASYNC and some use ESUB_NOMONITOR --- possibly they should be more consistent. I'll just apply it as it is. Cheers pws ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-04-10 8:43 UTC | newest] Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20190409183514epcas2p3d19839c97731d5b19dc05586ec9346c7@epcas2p3.samsung.com> 2019-04-09 18:34 ` [PATCH] Fix ctrl-c not working after process substitution Eric Freese 2019-04-10 8:42 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).