[PATCH] Fix ctrl-c not working after process substitution

[PATCH] Fix ctrl-c not working after process substitution

[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

Re: [PATCH] Fix ctrl-c not working after process substitution

[Peter Stephenson]

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