Hey!

Thanks for your PR. You are targeting branch "7.4" but it seems your PR description refers to branch "7.3".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

Strange, but this doesn't fix anything when I use your code in the reproducer.

Ah, you clearly haven't tested this. The reason it doesn't work is that the signal handlers are never set. You need to fix this so thatpcntl_signal($signal, $restoreHandler) is actually called.

The issue occurred when using QuestionHelper with ChoiceQuestion and a signal handler that calls exit().

The issue also occurs in a restarted process as well. While you have ensured that the terminal continues to work, you have unfortunately replaced any user signal handler with your own, which doesn't call exit, thus defeating the most common use of Ctrl-C. You've also wiped out the user signal handler for the remainder of the process after a choice question.

I've updated thereproducer so that the questions are called twice, which makes it more obvious where Ctrl-C has been called.

I think you need to do the following:

• save the signal handler for each signal and run it after you have reset the terminal in your handler. For a callable, invoke it, for SIG_DFL exit with an appropriate exit code, and for SIG_IGN do nothing more.
• restore these signal handlers afterwards (inrestoreTerminal).
• for Ctrl-C signals, perhaps echo^C in the handler so it is clear to the user that the signal has been received.

On review, I wondered if this implementation, if made to work, won't collide with signal handlers as managed by the application?

On review, I wondered if this implementation, if made to work, won't collide with signal handlers as managed by the application?

Provided that existing signal handlers are saved before the choice question, invoked as I described above if signalled in the choice question, then restored afterwards, then there shouldn't be any collisions. Well that's the theory, anyway.

You can verify the fix by running this command, which simulates a Ctrl-C during the interactive prompt and checks the terminal state before and after:

orig=$(stty -g); php sigbug handler& pid=$!; sleep 1;kill -INT$pid;wait$pid;echo"-- stty after --"; stty -a; stty$orig;echo"-- restored --"; stty -a

This test was performed on macOS with an M1 chip. Please let me know if you need assistance testing on other platforms or with the restart scenario.

Thanks for the fixes. However, registering lots of shutdown functions is not ideal or even necessary. I think you are making things a bit too complicated and could use something like this to set the SIGINT handler:

$signalHandler =null;if (\function_exists('pcntl_async_signals') &&\function_exists('pcntl_signal')) {pcntl_async_signals(true);$signalHandler =pcntl_signal_get_handler(\SIGINT);pcntl_signal(\SIGINT,function ($signo)use ($sttyMode,$signalHandler) {echo'^C', \PHP_EOL;shell_exec('stty'.$sttyMode);// Original handler will be a callable, SIG_DFL or SIG_IGNif (\is_callable($signalHandler)) {$signalHandler($signo);return;        }if ($signalHandler === \SIG_DFL) {exit(128 +$signo);        }    });}

Then call the following (either before throwing the exception and at the end of the function, or just once in a try, finally block);

// Restore terminal and original SIGINT handlershell_exec('stty'.$sttyMode);if ($signalHandler !==null) {pcntl_signal(\SIGINT,$signalHandler);}

You can verify the fix by running this command, which simulates a Ctrl-C during the interactive prompt and checks the terminal state before and after

This command does not work for me because it shows the same stty state with the broken code. In my terminal the signal stops the process, then restores the terminal so it can tell me it has done so and allow me to resume withfg #1.

Closing in favor of#61861, thanks for giving this a try!