zsh-workers
 help / Atom feed
* [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, back to index

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

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/ public-inbox