When spawned as a subprocess (only tested via python's subprocess.run()), hitting ctrl-c to send a SIGINT interrupt signal causes the shell to exit and return control to the parent process, instead of consuming the interrupt like a normally spawned shell. This does not occur when spawning other shells (I tested bash & zsh) in the same manner, but appears to be fish-specific.

This has been very annoying when using iocage to manage FreeBSD jails, as it unexpectedly exits the jail and appears to corrupt input in the parent shell -- however, I've never naturally encountered the issue outside that workflow.

Steps to reproduce:

1. Run the following python code to spawn a new shell:

import subprocess

try:
    subprocess.run(["fish", "-i"])
    # User hits ctrl-c here
except KeyboardInterrupt:
    print("Aborted!")

2. Hit ctrl-c to send an interrupt, and you will see "Aborted!", indicating the subprocess has exited

Spawning a different shell (e.g. subprocess.run(["bash", "-i"])) does not reproduce this behavior. Further, if the parent shell is bash instead of fish, typed characters do not display on the terminal after the subprocess's exit, but will register as a command once Enter is pressed.

I noticed that bash (and other shells) are the leader of their own process group during this maneuver, and fish is not. I'm not well-versed on process-control flow, but this seems related since signals from the terminal are sent to all processes in the foreground process group:

> ps a -o pid,pgid,tpgid,command | grep -A2 "python ctrl_c.py"
  PID  PGID TPGID COMMAND
----------------------------------
20187 20187 20188 python ctrl_c.py
20188 20188 20188 bash -i
----------------------------------
19997 19997 19997 python ctrl_c.py
19998 19997 19997 fish -i

• fish: 3.0.2
• OS: Arch Linux
• Terminal: urxvt (rxvt-unicode-256color)
• Third-party customizations have no effect