fish-shell/tests/pexpects/sigint.py

#!/usr/bin/env python3
from pexpect_helper import SpawnedProc

sp = SpawnedProc()
sendline, sleep, expect_prompt, expect_str = (
    sp.sendline,
    sp.sleep,
    sp.expect_prompt,
    sp.expect_str,
)

# Ensure that if child processes SIGINT, we exit our loops.
# This is an interactive test because the parser is expected to
# recover from SIGINT in interactive mode.
# Test for #7259.

expect_prompt()
sendline("while true; sh -c 'echo Here we go; sleep .25; kill -s INT $$'; end")
sleep(0.30)
expect_str("Here we go")
expect_prompt()
sendline("echo $status")
expect_str("130")
expect_prompt()

sendline("echo it worked")
expect_str("it worked")
expect_prompt()
Correctly propagate signals from cancelled jobs into parse_execution_context This concerns code like the following: while true ; sleep 100; end Here 'while' is a "simple block execution" and does not create a new job, or get a pgid. Each 'sleep' however is an external command execution, and is treated as a distinct job. (bash is the same way). So `while` and `sleep` are always in different job groups. The problem comes about if 'sleep' is cancelled through SIGINT or SIGQUIT. Prior to 2a4c545b21, if any process got a SIGINT or SIGQUIT, then fish would mark a global "stop executing" variable. This obviously prevents background execution of fish functions. In 2a4c545b21, this was changed so only the job's group gets marked as cancelled. However in the case of one job group spawning another, we weren't propagating the signal. This adds a signal to parse_execution_context which the parser checks after execution. It's not ideal since now we have three different places where signals can be recorded. However it fixes this regression which is too important to leave unfixed for long. Fixes #7259 2020-08-12 21:35:37 -07:00			`#!/usr/bin/env python3`
			`from pexpect_helper import SpawnedProc`

			`sp = SpawnedProc()`
			`sendline, sleep, expect_prompt, expect_str = (`
			`sp.sendline,`
			`sp.sleep,`
			`sp.expect_prompt,`
			`sp.expect_str,`
			`)`

			`# Ensure that if child processes SIGINT, we exit our loops.`
			`# This is an interactive test because the parser is expected to`
			`# recover from SIGINT in interactive mode.`
			`# Test for #7259.`

			`expect_prompt()`
			`sendline("while true; sh -c 'echo Here we go; sleep .25; kill -s INT $$'; end")`
			`sleep(0.30)`
			`expect_str("Here we go")`
			`expect_prompt()`
Remove cancellation groups Cancellation groups were meant to reflect the following idea: if you ran a simple block: begin cmd1 cmd2 end then under job control, cmd1 and cmd2 would get separate groups; however if either exits due to SIGINT or SIGQUIT we also want to propagate that to the outer block. So the outermost block and its interior jobs would share a cancellation group. However this is more complex than necessary; it's sufficient for the execution context to just store an int internally. This ought not to affect anything user-visible. 2022-03-20 14:32:18 -07:00			`sendline("echo $status")`
			`expect_str("130")`
Add missing expect_prompt to test_sigint.py Somehow the Rust port of reader requires this. 2023-12-22 12:27:01 +01:00			`expect_prompt()`
Correctly propagate signals from cancelled jobs into parse_execution_context This concerns code like the following: while true ; sleep 100; end Here 'while' is a "simple block execution" and does not create a new job, or get a pgid. Each 'sleep' however is an external command execution, and is treated as a distinct job. (bash is the same way). So `while` and `sleep` are always in different job groups. The problem comes about if 'sleep' is cancelled through SIGINT or SIGQUIT. Prior to 2a4c545b21, if any process got a SIGINT or SIGQUIT, then fish would mark a global "stop executing" variable. This obviously prevents background execution of fish functions. In 2a4c545b21, this was changed so only the job's group gets marked as cancelled. However in the case of one job group spawning another, we weren't propagating the signal. This adds a signal to parse_execution_context which the parser checks after execution. It's not ideal since now we have three different places where signals can be recorded. However it fixes this regression which is too important to leave unfixed for long. Fixes #7259 2020-08-12 21:35:37 -07:00
			`sendline("echo it worked")`
			`expect_str("it worked")`
			`expect_prompt()`