Bug report

Bug description:

Thedocs forreturncode state the following:

A negative value-N indicates that the child was terminated by signalN (POSIX only).

which does not technically require, but strongly suggest that processes terminated by signals will have a negativereturncode corresponding to the signal. On some platforms (observed on Arch Linux and macOS, both using Python 3.13.7), this does indeed seem to be the case. On others it is not. The observed counterexample is Ubuntu using Python 3.12.3. There,returncode seems to be set to 128 + signal value. Technically, this does not violate the documented behavior, but it is very surprising. If that is intended behavior, the docs deserve a clear warning. My preference would be to mandate negativereturncodes upon termination by signal in the docs and to adapt the code on non-conformant platforms accordingly.

Interestingly,asyncio.create_subprocess_exec has the expected behavior of consistently negativereturncodes on the tested platforms, which increases my suspicion that there is indeed undesired behavior involved.

importasyncioasyncdefrepro():proc=awaitasyncio.create_subprocess_shell("./sigint.sh")awaitproc.communicate()print(proc.returncode)assertproc.returncode==-2asyncio.run(repro())

sigint.sh:

#!/bin/shkill -2$$

I created a repo to show the differences in GitHub's CI:https://github.com/danielrainer/python_signal_returncode_repro/actions/runs/17310888203

CPython versions tested on:

3.13, 3.12

Operating systems tested on:

Linux, macOS

Linked PRs

• gh-138234: clarify returncode behavior for subprocess_exec vs subprocess_shell #138536
• [3.14] gh-138234: clarify returncode behavior for subprocesses created withshell=True (GH-138536) #146254
• [3.13] gh-138234: clarify returncode behavior for subprocesses created withshell=True (GH-138536) #146255