A shell script and a small C program both run correctly on Linux but misbehave on another Unix system such as macOS or AIX. What does POSIX actually guarantee, and what does it deliberately leave unspecified that would explain failures like these?

## What POSIX is POSIX is IEEE Std 1003.1, developed by the Austin Group and published jointly with The Open Group, where it also forms the core of the Single UNIX Specification. It exists because the Unix family fragmented in the 1980s into incompatible commercial variants, and customers wanted a written contract for what "Unix" meant. The current edition is POSIX.1-2024, also known as Issue 8 of the Single UNIX Specification; POSIX.1-2017 is the previous edition and is still what a great deal of documentation cites. It covers three volumes' worth of surface: - **System interfaces** — the C API: `open`, `read`, `fork`, `execve`, `waitpid`, `sigaction`, `pthread_*`, `select`, `poll`, and the headers that declare them, with defined error numbers and behaviours. - **Shell and utilities** — the shell command language itself (grammar, expansion, quoting, redirection) plus a catalogue of utilities such as `sed`, `awk`, `grep`, `find`, `sort`, `printf`, each with the options and semantics an implementation must provide. - **Environment and locale behaviour** — environment variables, locale categories, character-set handling. ## What it deliberately does not cover **Binary compatibility.** POSIX is a *source*-level contract. There is no promise that an executable built on one conforming system runs on another; that is an ABI question, and ABIs are per-platform. Two POSIX systems can differ in calling convention, object format and libc entirely. **Anything above the minimum.** The standard says what an implementation must accept, not what it must refuse. A vendor may add options freely, and every major vendor has. GNU coreutils in particular is far larger than the POSIX catalogue. Writing against the union of everything installed on your machine is the single commonest way to produce non-portable code that looks fine. **Kernel-specific interfaces.** Event notification is the standard example: POSIX gives you `select` and `poll`; Linux adds `epoll`, FreeBSD and macOS add `kqueue`, and neither is in the standard. Filesystem-change notification, process introspection through a `/proc` filesystem, containers, capability models and resource-control mechanisms are all outside POSIX entirely. **System organisation.** Package management, service supervision and init, the location of most files, the network configuration model, and the machine's boot process are not POSIX concerns. Only a handful of paths are actually specified — `/dev/null`, `/dev/tty`, `/dev/console` and `/tmp` among them. ## The concrete failures behind the question **GNU userland versus BSD userland.** macOS ships BSD-derived utilities. `sed -i 's/a/b/' f` works on Linux because GNU sed makes the backup suffix optional; BSD sed requires an explicit argument, so it consumes the script as the suffix and fails. `date -d 'yesterday'` is a GNU extension; BSD `date` uses `-v` for adjustment and `-j -f` for parsing. GNU long options such as `--recursive` are extensions. `grep -P` for Perl-compatible patterns is GNU-only. **Unspecified behaviour that happens to work.** `echo -e` is the classic: POSIX leaves `echo`'s treatment of options and backslash escapes unspecified precisely because implementations disagreed, and directs you to `printf` when you need escapes. Code that relies on `echo -e` is not portable even though it is ubiquitous. ```sh # unspecified across Unix systems echo -e "a\tb" # portable printf 'a\tb\n' ``` **Which shell `/bin/sh` actually is.** POSIX defines the shell *language*; it does not say which program provides it. Some systems point `/bin/sh` at a small strictly-POSIX shell, others at a larger shell running in a compatibility mode. A script whose shebang says `sh` but which uses non-POSIX syntax works on one and dies on the other. **Locale.** Sorting order, character ranges in bracket expressions, and case conversion are locale-dependent. The same `sort` on the same input yields different order under a different `LC_COLLATE`, which is why deterministic pipelines set `LC_ALL=C`. **C-side surprises.** Functions that feel standard often are not: `strlcpy` originated in BSD and was absent from GNU's C library for a very long time. The presence of a `/proc` filesystem, the exact set of `errno` values a call can return, and sizes of types beyond what the language standard fixes are all places where "it compiled on my machine" fails. ## How to actually get portability Decide your target set explicitly, then test against it — a conformance claim is not a substitute for running the code on a second system. Prefer the POSIX-specified option set and `printf` over `echo`; pin locale where ordering matters; feature-test rather than assume in C, and guard platform-specific calls behind a compile-time selection with a portable `poll`-based fallback. And be honest in the interview that in current practice most teams choose *one* target and control it with an image, rather than chasing full portability — knowing where the standard's edge is matters most for the moments when you cross it.