You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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!")
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:
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:
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 onceEnter
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:
The text was updated successfully, but these errors were encountered: