Exit Status¶
A small value produced when a process terminates and made available to its parent or caller to summarize whether and, by convention, how the execution completed.
Core Idea¶
Exit status turns termination into a machine-readable control signal. It is deliberately small and out-of-band from ordinary program output so callers can branch without parsing prose.
The number has no universal detailed meaning. Correct use requires the producer's code table, the operating system's termination encoding, and the caller's rules for pipelines, signals, and wrappers.
Scope of Application¶
- Shell scripting. Controls conditional and pipeline execution.
- Process supervision. Detects failure and selects restart policy.
- Build and CI systems. Summarizes command completion.
- Command design. Publishes stable automation contracts.
Clarity¶
State producer, lifecycle boundary, normal or abnormal termination, full raw wait result, extracted exit code, width and range, zero convention, code table, pipeline policy, wrapper behavior, retry semantics, and where richer diagnostics are stored. Inclusion test: Require a value associated with process or callable-unit termination and exposed to a caller under a declared convention. Exclusion test: Exclude standard output, exception text, logs, HTTP status codes, application state before termination, and a function's ordinary return value unless it is specifically propagated as the process exit status. Nearest boundary: A signal number or wait status can encode why a process ended; the exit status is the conventional completion value extracted or reported by the platform. Exit condition: Meaning is lost when wrappers overwrite the code, shells truncate it, pipelines report a different member, or callers assume zero/nonzero without the program contract. Common misclassifications: It is not the program's printed error message. It is not universally an errno value. Nonzero details are program-specific. A wrapper can hide the child process's original status. Nearest named distinctions: Function return value: Returns within a process and may never become its exit code. Error number: Identifies a runtime or library error under another convention. Termination signal: Describes abnormal ending rather than a normal chosen code. Standard error: Is a byte stream, not the caller's completion value.
Manages Complexity¶
One integer sits between program-specific failure taxonomies and platform-specific process semantics. Composition through shells, containers, remote execution, and supervisors can silently transform which code is observed.
Abstract Reasoning¶
- Identify the exact process whose completion matters.
- Separate normal exit code from signal or exception termination.
- Retrieve status without overwriting it in an intervening command.
- Interpret it using the executable's documented contract and platform rules.
- Preserve raw status and diagnostic context when wrappers, pipelines, or retries transform control flow.
Knowledge Transfer¶
Compact completion signaling transfers to jobs and workflow steps, but numeric codes and termination modes remain runtime-specific. HTTP responses and language exceptions are neighboring protocols, not process exit statuses.
Relationships to Other Abstractions¶
Current abstraction Exit Status Domain-specific
Parents (1) — more general patterns this builds on
-
Exit Status presupposes Interface Prime
Exit Status presupposes Interface: the parent's defining role is necessary to the child's frozen mechanism or criterion.
Neighborhood in Abstraction Space¶
Exit Status sits in a crowded region of the domain-specific corpus (35th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.
Family — Computer Systems & Network Architecture (20 abstractions)
Nearest neighbors
- Zombie process — 0.89
- Generalized Büchi Automaton — 0.88
- Protection Ring — 0.88
- Verifiable Computing — 0.88
- Type Error — 0.88
Computed from structural-signature embeddings · 2026-10-08