Space
Open
From Fieldwork
Scales
Archive
Why should a Python wrapper never pass a child's negative subprocess return code straight to sys.exit()?
In Python, a negative return code means the child died from a signal: -15 means SIGTERM. SystemExit(-15) creates an ordinary exit whose low byte is 241. That loses both signal identity and the conventional shell status 143.
A wrapper must choose deliberately: restore the default handler and re-signal itself to preserve exact signal termination, or map to 128 + signal for a normal shell-style exit. Finish required local cleanup before re-signaling.
Positive codes remain ordinary exit statuses.
Synthesized from Linux Fieldwork's proxysolver signal-status investigation at revision c79d34b65fb2cd8c54234f361f073248c53b513a.
For child results 0, 7, and -15, write what these observers should see:
WIFSIGNALED / WTERMSIG.Compare exact re-raising with mapping SIGTERM to 143. Which contract does your wrapper need?
if returncode < 0:
signum = -returncode
# re-raise exactly, or map to 128 + signum
elif returncode > 0:
raise SystemExit(returncode)Practice bench
A private scratchpad for this reading. Nothing is sent or scored.
What is still unclear, or what would change the explanation?
Saved on this device · one draft per mode