Ctrl-C does not interrupt brush while an external utility is running

[avih]

brush version

master

bash version (for comparison)

No response

Platform / OS

Linux

Steps to reproduce

Run the following:

brush -c 'while :; do printf X; sleep 1; done'

and try to abort it using ctrl-C.

Similar scenario with the same symptoms: run an interactive brush shell, and then at the prompt run this line:

while :; do printf X; sleep 1; done

Actual behavior (brush)

It's effectively impossible to abort it (both test cases), despite many attempts with ctrl-C.

Expected behavior

With brush -c ...: brush always exits on first ctrl-C press.

With interactive brush shell: brush aborts the loop, prints the prompt, and is ready for new user input.

Additional context

First, this issue happens in both linux (musl) brush, and windows-brush. I did not test other binaries.

Here's an example terminal printout with quite a few ^C presses, sometimes several-per-second, and after giving up, killing it from another terminal (pkill brush - that was the only brush process running):

$ ./brush -c 'while :; do printf X; sleep 1; done'
XXXXXXX^CX^CXX^CX^CX^CX^CX^CX^CX^CX^CX^CX^CX^CXXX^CX^CX^CX^CX^CXXXTerminated

As evident from the output, and even more so when watching it unfold at the terminal, every ctrl-C press is immediately followed by a printout of X. This is even more evident if using e.g. sleep 10 instead of sleep 1.

So the ^C does interrupt the currently-running command (99.99999% of the attempts would be at the sleep 1 command), and then brush continues with the loop as if nothing happened, and the process just happened to exit.

However, testing this exact line with any other shell (tested dash, bash, zsh, busybox-ash), and the first ^C always exits that loop and the shell.

So when an interrupt happens while an external utility was running, brush should instead also apply it to whatever (shell) code which invoked that utility. Typically this means calling the trap code, if exists, and if not then exit that code/loop/shell/etc.

Care should be taken to not exit the shell itself if it's interactive.

[avih]

So when an interrupt happens while an external utility was running, brush should ...

Actually, a more accurate condition would be:

When an external utility exits due to an interrupt... etc.

I.e. in contrast to "when an interrupt happpened ...", because if the utility handled it itself and didn't exit, then brush should not get interrupted.

Here's a procedure to demonstrate this difference:
Save the following as 3c:

#!/bin/sh

# loop forever on sleep 1 loop by default.
# exit if ctrl-C was pressed 3 times.

x=2
trap '[ $((x=x-1)) -gt 0 ] || { echo "[ONCE MORE TO EXIT...]"; trap - INT; }' INT

while :; do sleep 1; done

and make it executable using chmod +x 3c.

This utility (which happens to be a /bin/sh script) runs forever by default, and exits after pressing ^C 3 times (just try ./3c).

Now run it in a loop from brush:

brush -c 'while :; do ./3c; done'

Similar to the original test case, it's effectively impossible to interrupt it with ^C. Here's a sample output from the terminal (which was killed from another terminal after giving up):

$ ./brush -c 'while :; do ./3c; done'
^C^C[ONCE MORE TO EXIT...]
^C^C^C[ONCE MORE TO EXIT...]
^C^C^C[ONCE MORE TO EXIT...]
^C^C^C[ONCE MORE TO EXIT...]
^C^CTerminated

So ./3c exits due to an interrupt after 3 times ^C, but brush keep running it forever in a loop.

In contrast, with any other shell (tested bash, dash, zsh, busybox-ash), it exits after 3 times ^C:

$ bash -c 'while :; do ./3c; done'
^C^C[ONCE MORE TO EXIT...]
^C
$

What this means is that it's not enough that "interrupt happened while external utility ...", but that it also actually exited due to that interrupt - in order to also interrupt brush itself. But if the utility handled the interrupt and didn't exit - then brush should also not be interrupted.

As a side note, the interpretation of "uttility exited due to an interrupt" can differ between shells.

The 3c script above disables the trap after ^C was pressed twice, meaning that the 3rd time it's pressed - there's no more trap to handle it, and it exits more or less directly due to the interrupt.

However, if we change the trap lines from

x=2
trap '[ $((x=x-1)) -gt 0 ] || { echo "[ONCE MORE TO EXIT...]"; trap - INT; }' INT

into:

x=3
trap '[ $((x=x-1)) -gt 0 ] || { echo "[DONE]"; exit; }' INT

then it doesn't exit "directly" from the 3rd ^C interrupt. Instead, it does identify the 3rd ^C, but then exits "normally".

In this case, while dash, zsh, and busybox ash do identify it as "exited due to an interrupt" - and also exit the loop on 3rd ^C, bash keeps running 3c in a loop forever, depite every 3rd ^C exiting 3c.

I don't know the technical details of how each shell detects "exited due to an interrupt", but I do like the zsh/dash/busybox behavior more than the bash behavior, because, at least from a user perspective, 3c did exit due to the 3rd ^C.