Linux concept: POSIX

Een script werkt op je laptop. Je kopieert het naar de server, het draait om drie uur 's nachts vanuit cron, en het crasht op een regel die niet is veranderd. Niemand heeft eraan gezeten, er is geen pakket bijgewerkt, en hetzelfde bestand werkt nog steeds als je het met de hand start. De oorzaak is meestal geen fout in je logica. Het is dat de twee machines het oneens zijn over wat een Unix-systeem is, en het document dat bepaalt wie gelijk heeft heet POSIX.

Dit artikel legt uit wat POSIX echt is, waar de naam vandaan komt, hoe veertig jaar Unix-ruzie het heeft opgeleverd, en hoe je het gebruikt: je eigen systeem vragen welke versie het implementeert, de standaard gratis lezen, shell-scripts schrijven die een verhuizing naar een andere machine overleven, en de feature test macro's die bepalen welke functies je C-compiler wil erkennen. Onderweg scheidt het de C-bibliotheek van de kernel, en portabiliteit van broncode van compatibiliteit van binaries. Het behandelt ook wat POSIX niet is, want daar zit de meeste verwarring.

Schrijf je alleen shell-scripts, dan kun je sectie 6 overslaan: die is voor wie C schrijft of compileert, en de rest van het artikel bouwt er niet op voort.

Van "waarom brak mijn script op de server" naar "wie van deze twee systemen heeft het mis".

Het doel: na het lezen kun je bij elk portabiliteitsprobleem zeggen of de standaard er een uitspraak over doet.

2. Waar de naam vandaan komt

POSIX staat voor Portable Operating System Interface. Lees de woorden op volgorde en ze beschrijven het hele project: een interface naar een besturingssysteem, zo vastgelegd dat software overdraagbaar is tussen systemen die hem bieden.

De laatste letter komt niet uit die woorden. Er zit geen X in "Portable Operating System Interface", en de standaard eindigt er toch op door een naamgewoonte: de Unix-systemen van die tijd heetten AIX, IRIX, HP-UX, Ultrix, Xenix, en een X aan het eind las als "dit hoort bij de Unix-familie". De naam is met opzet uitspreekbaar, en hij bleef meteen hangen.

Wie hem heeft voorgesteld staat vastgelegd in de Linux-handleidingen. Draai man 7 standards en lees het stuk over de eerste uitgave:

$ man 7 standards
POSIX.1-1988
       This was the first POSIX standard, ratified by IEEE as IEEE Std
       1003.1-1988, and subsequently adopted (with minor revisions) as
       an ISO standard in 1990.  The term "POSIX" was coined by Richard
       Stallman.

De IEEE-werkgroep had een naam nodig voor een document dat tot dan toe alleen bij zijn commissienummer bekend was. Dat nummer is nooit verdwenen, en daarom kom je dezelfde standaard onder meerdere namen tegelijk tegen:

Een letter achter het nummer betekent een aanvulling en geen nieuwe uitgave. POSIX.1b voegde in 1993 realtime-voorzieningen toe en POSIX.1c in 1995 threads, en allebei zijn ze later in het hoofddocument opgenomen. Zie je 1003.1c in een handleiding staan, dan vertelt die je dat een functie met de threads-aanvulling is gekomen.

Het beeld dat de naam beschrijft is één lijn dwars door een draaiend systeem:

    your program        your shell script
    ------------------------------------------   <-- POSIX describes this line
    system calls    C library    sh    utilities
    ------------------------------------------
    the kernel and the hardware underneath

Alles boven de lijn is van jou. Alles eronder is de zaak van de implementatie, en de standaard zegt niets over hoe dat gebeurt. POSIX heeft het nergens over inodes op schijf, over planningsalgoritmes, of over hoe een bestandssysteem is ingedeeld. Het legt alleen vast hoe de laag er van bovenaf uitziet, en dat is precies wat een programma moet weten en niets meer.

4. Eenvoudige toepassingen: POSIX op je prompt

POSIX klinkt als iets waar alleen normcommissies aan zitten. In werkelijkheid staan er op je systeem meerdere programma's waarvan het enige doel is er vragen over te beantwoorden, en het loont om ze te kennen voordat je ze nodig hebt.

4.1 Het systeem vragen wat het biedt

getconf zonder argumenten geeft één waarde; met -a (kort voor all) dumpt het alles wat het systeem weet. Dat filteren is de snelste manier om te zien welke optionele delen van de standaard aanwezig zijn:

$ getconf -a | grep -E '_POSIX_(VERSION|THREADS|TIMERS|SPAWN|SHELL)'
_POSIX_THREADS                     200809
_POSIX_TIMERS                      200809
_POSIX_VERSION                     200809
_POSIX_SHELL                       1
_POSIX_SPAWN                       200809

Lees die waarden als antwoorden op ja-nee-vragen. Een datum betekent "deze optionele functionaliteit is aanwezig, op het niveau van deze uitgave van de standaard". Een 1 betekent "aanwezig", een lege waarde betekent "hier niet ondersteund". Threads, timers en posix_spawn() zijn in de tekst van de standaard allemaal optionele onderdelen, ook al heeft elk systeem voor algemeen gebruik ze al twintig jaar.

Hetzelfde programma rapporteert de limieten van het systeem, en die zijn nuttiger dan ze lijken:

$ getconf ARG_MAX          # bytes available for a command line
2097152
$ getconf LINE_MAX         # longest input line a text utility must handle
2048
$ getconf NAME_MAX /       # longest single filename on this filesystem
255
$ getconf PATH_MAX /       # longest full path
4096

ARG_MAX is het getal achter de foutmelding "Argument list too long", en het is de reden dat find ... -exec cmd {} + en xargs bestaan. NAME_MAX en PATH_MAX krijgen een pad mee omdat het antwoord afhangt van het bestandssysteem dat daar gekoppeld is, en niet van het systeem als geheel.

4.2 Het standaard-PATH

POSIX legt een waarde voor PATH vast waarmee je gegarandeerd de standaardprogramma's vindt, en getconf geeft hem je zo:

$ getconf PATH
/bin:/usr/bin

Dit is de waarde die je gebruikt als een script niet mag afhangen van het PATH dat het toevallig heeft geërfd. De shell heeft daar een bijpassend hulpmiddel voor: command -p (kort voor path) zoekt de opdracht op in precies dat standaard-PATH en negeert dat van jou:

$ command -p -v ls
/bin/ls

Dat telt in een cronjob, in een systemd-unit, of in alles wat onder sudo draait, want daar is het PATH niet hetzelfde als waarmee jij hebt getest. Werkt een script op je prompt en faalt het vanuit cron met "command not found", dan is het PATH het eerste om te controleren, en command -p is de portabele manier om er niet meer om te hoeven geven.

4.3 De standaard zelf lezen

De standaard is geen geheim document achter een betaalmuur. The Open Group publiceert de volledige tekst gratis als HTML op pubs.opengroup.org, en dat is de bron om aan te halen in elke discussie over portabiliteit. Hij is bovendien leesbaar: elke pagina over een programma heeft dezelfde indeling, met SYNOPSIS, OPTIONS, een EXAMPLES-sectie en een RATIONALE waarin staat waarom de commissie koos wat ze koos.

Je kunt hem ook als handleidingen lezen. De POSIX-tekst komt als eigen handleidingsecties, waarbij 1p de programma's zijn en 3p de functies:

$ man 1p ls
No manual entry for ls in section 1p

Die pagina's zitten in een apart pakket, omdat de licentie van de standaard niet vrij genoeg is voor de hoofdarchieven. Op Debian en Ubuntu staat het in multiverse:

$ sudo apt install manpages-posix manpages-posix-dev
$ man 1p ls            # what the standard says about ls
$ man 3p open          # what the standard says about open()

Het verschil tussen man 1 ls en man 1p ls is precies waar dit artikel over gaat. De eerste vertelt je wat jouw ls doet. De tweede vertelt je wat elke ls moet doen. Als ze het oneens zijn, is het extra gedrag een lokale uitbreiding, en die gebruiken is een keuze in plaats van een ongelukje.

Nog twee pagina's zijn het bewaren waard, en allebei staan ze al op je systeem:

$ man 7 standards        # every standard a STANDARDS section can name
$ man 7 posixoptions     # the optional units and how to test for them

4.4 Controleren of een bestandsnaam portabel is

POSIX legt een portable filename character set vast: letters, cijfers, punt, liggend streepje en koppelteken. Het programma pathchk toetst namen daaraan, met -p voor portable:

$ pathchk -p 'My File.txt'
pathchk: non-portable character ' ' in file name 'My File.txt'
$ pathchk -p 'a+b'
pathchk: non-portable character '+' in file name 'a+b'
$ pathchk -p 'report_1.txt'
$ echo $?
0

Stilte betekent dat de naam veilig is. Dit gaat niet over wat Linux accepteert, want dat is zo ongeveer elke byte behalve / en NUL. Het gaat over wat een reis overleeft door een ander systeem, een archiefformaat, of een script dat vergat een variabele te quoten.

-p toetst ook de lengte aan de standaard, en die is strenger dan elk systeem dat je deze eeuw hebt gebruikt:

$ pathchk -p 'backup-2026.tar.gz'
pathchk: limit 14 exceeded by length 18 of file name component
         'backup-2026.tar.gz'

Veertien tekens is de ondergrens die POSIX garandeert voor één stuk van een bestandsnaam, een getal dat is overgenomen uit de vroege Unix-bestandssystemen. Jouw bestandssysteem staat er 255 toe, en daarom loopt niemand hier tegenaan. Het is een mooie illustratie van wat -p betekent: niet "werkt dit hier", maar "werkt dit op het kleinste systeem dat de standaard nog toestaat".

6. Gevorderde toepassingen: POSIX in C

De andere helft van de standaard is de C-interface, en die bepaalt iets wat mensen de eerste keer verrast: welke functies je compiler wil erkennen.

Compileer je zelf nooit C, ga dan meteen door naar sectie 7. Niets daarin bouwt voort op deze sectie, en de C-punten in de lijsten verderop zijn korte samenvattingen van wat hier volgt.

6.1 De C-bibliotheek is de laag, niet de kernel

POSIX beschrijft een interface voor programma's, en op Linux wordt die interface geleverd door de C-bibliotheek, niet door de kernel. Jouw programma roept een standaardfunctie aan; de C-bibliotheek bepaalt wat er aan de kernel wordt gevraagd:

your program
     |
POSIX functions:  open()  fork()  pthread_create()
     |
the C library:  glibc, or musl on a smaller system
     |
the Linux system call interface
     |
the kernel

Die twee middelste lagen zijn niet dezelfde lijst, en één opdracht laat dat zien. POSIX legt fork() vast. Linux heeft ook echt een fork-systeemaanroep, en glibc gebruikt hem niet: het maakt het kindproces met clone(), omdat die ene aanroep processen en threads samen afdekt.

$ strace -f -e trace=clone,fork ./forktest
clone(child_stack=NULL,
      flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, ...) = 16716
+++ exited with 0 +++

Het programma riep fork() aan. De kernel kreeg clone() te verwerken. Er is niets kapot: een POSIX-functie is een belofte over gedrag, geen naam van een systeemaanroep. Sommige functies zijn dunne omhulsels, sommige zijn uit een andere aanroep opgebouwd, en delen van pthread leven vooral in de bibliotheek.

Daar volgen twee dingen uit. POSIX zegt niets over welke systeemaanroepen bestaan of hoe ze genummerd zijn, dus de kernel mag veranderen hoe een functie wordt uitgevoerd zolang die functie zich blijft gedragen zoals vastgelegd. En conformiteit is een eigenschap van een heel systeem - kernel, C-bibliotheek, shell en programma's samen - en daarom heeft "is Linux POSIX?" geen net antwoord. Linux is de kernel. Wat POSIX implementeert is de distributie.

6.2 Feature test macro's

Hier is een programma dat strdup() gebruikt, een functie die sinds 2008 in POSIX zit en al veel langer in elke C-bibliotheek:

#include <stdio.h>
#include <string.h>

int main(void) {
    char *copy = strdup("hello");
    printf("%s\n", copy);
    return 0;
}

Compileer het als strikte C99 en de compiler zegt dat de functie niet bestaat:

$ gcc -std=c99 -Wall -o t t.c
t.c: In function 'main':
t.c:4:18: warning: implicit declaration of function 'strdup';
                   did you mean 'strcmp'?

Er ontbreekt niets aan je systeem. strdup() zit in de C-bibliotheek, en de linker vindt hem gewoon. Wat er gebeurde is dat -std=c99 om de ISO C-taal vroeg en om niets meer, en strdup() zit niet in ISO C: het is POSIX. Dus verstopte de header hem.

De schakelaar die hem tevoorschijn haalt is een feature test macro, gedefinieerd voordat er een header wordt ingelezen, of op de opdrachtregel:

$ gcc -std=c99 -D_POSIX_C_SOURCE=200809L -Wall -o t t.c
$ ./t
hello

Het getal is dezelfde datumcodering als eerder: vraag om de uitgave van 2008 en je krijgt alles wat die uitgave vastlegt. Vraag om 199309L en je krijgt de kleinere verzameling van de aanvulling uit 1993. De macro's zijn een manier om te zeggen tegen welke standaard je schrijft, en de headers laten je precies zoveel zien:

Dit is waarom hetzelfde bronbestand op je laptop compileert en faalt in een container met een strengere bouwvlag, en waarom handleidingen in de SYNOPSIS een regel hebben die vertelt welke macro een functie nodig heeft. man 7 feature_test_macros is het volledige naslagwerk, en het is een van de nuttigste pagina's op het systeem.

De koppeling is zichtbaar in de headers zelf:

$ grep -n 'define _POSIX_VERSION' /usr/include/unistd.h
34:# define _POSIX_VERSION	200809L
37:# define _POSIX_VERSION	200112L
40:# define _POSIX_VERSION	199506L
43:# define _POSIX_VERSION	199309L
46:# define _POSIX_VERSION	199009L

Vijf definities in één bestand, binnen een reeks #if-takken. Welke macro je ook hebt gevraagd, hij kiest er één van, en jouw programma ziet daarna de versie van de interface die daarbij hoort.

6.3 Hoe POSIX-functies fouten melden

Bijna elke functie in de standaard meldt problemen op dezelfde manier: een retourwaarde die zegt dat er iets mis is gegaan, en de variabele errno die zegt wat. De standaard legt de foutnamen vast, en daarom betekent ENOENT hetzelfde op Linux, op macOS en op AIX:

#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>

int main(void) {
    int fd = open("missing.txt", O_RDONLY);
    if (fd == -1) {
        int saved = errno;          /* copy it on the very next line */
        printf("failed: errno %d, %s\n", saved, strerror(saved));
    }
    return 0;
}

$ ./err
failed: errno 2, No such file or directory

Bij errno horen twee regels, en allebei staan ze in de standaard en niet in de folklore. Ten eerste: lees hem pas nadat een aanroep je heeft verteld dat hij faalde. Een geslaagde aanroep mag hem veranderen, en niemand zet hem voor je op nul, dus een oude waarde uit een eerdere aanroep is de gebruikelijke reden dat een foutmelding het verkeerde probleem noemt. Ten tweede: lees hem meteen. Elke bibliotheekaanroep ertussen, ook printf(), mag hem overschrijven. Daarom kopieert het voorbeeld hem naar saved voordat het iets anders doet.

De fout die je bij naam moet kennen is EINTR. Een blokkerende aanroep die door een signaal wordt onderbroken kan daarmee terugkeren in plaats van af te maken, dus portabele code moet beslissen of hij het opnieuw probeert. man 7 signal is het naslagwerk, en die pagina noemt ook een plek waar Linux verder gaat dan de standaard: een blokkerende aanroep kan hier falen met EINTR nadat het proces is gestopt en hervat, en volgens de pagina "is not sanctioned by POSIX.1, and doesn't occur on other systems".

6.4 Vragen tijdens het compileren en tijdens het draaien

Dezelfde vraag heeft twee antwoorden, en ze door elkaar halen is een echte fout. Een programma kan de constante uit <unistd.h> lezen die bij het compileren vaststond:

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("%ld\n", (long) _POSIX_VERSION);
    return 0;
}

$ gcc -o v v.c && ./v
200809

Dat is wat de headers op de bouwmachine zeiden. Om het de machine te vragen waar het programma echt op draait, gebruik je de functies die tijdens het draaien werken: sysconf() voor systeembrede waarden, pathconf() en fpathconf() voor waarden die van een bestandssysteem afhangen, en confstr() voor tekstwaarden zoals het standaard-PATH. getconf uit sectie 4.1 is een dun omhulsel om precies deze drie.

Het onderscheid telt bij limieten. De constanten waarvan de naam met _POSIX_ begint zijn het minimum dat de standaard garandeert, niet de grootte van iets op jouw machine. De twee getallen liggen niet dicht bij elkaar:

$ grep -n '_POSIX_NAME_MAX\|_POSIX_PATH_MAX' \
      /usr/include/x86_64-linux-gnu/bits/posix1_lim.h
74:#define	_POSIX_NAME_MAX		14
97:#define	_POSIX_PATH_MAX		256

$ getconf NAME_MAX /       # what this filesystem really allows
255
$ getconf PATH_MAX /
4096

Een systeem dat de standaard volgt moet een naamdeel van 14 tekens en een pad van 256 toestaan. Dit systeem staat 255 en 4096 toe. Schrijf voor de ondergrens als je code overal moet draaien, maar zet geen van beide getallen vast in een buffergrootte: vraag het tijdens het draaien, op het pad dat je gaat gebruiken, want het antwoord verschilt tussen een lokale ext4-koppeling en een netwerkschijf op hetzelfde systeem.

6.5 De optionele delen

Niet alles in POSIX is verplicht. Hele gebieden zijn optionele onderdelen die een systeem dat de standaard volgt mag weglaten, en elk ervan heeft een macro om op te testen. Threads, realtime-signalen, berichtenwachtrijen, asynchrone I/O en gedeeld geheugen vallen allemaal in die categorie:

$ man 7 posixoptions      # the full list, with the sysconf name for each

Op een Linux-systeem voor algemeen gebruik is bijna alles aanwezig, en daarom merk je hier zelden iets van. Het gaat tellen zodra je doel kleiner is: een embedded systeem, een minimale container-image met musl in plaats van glibc, of een realtime-variant. De juiste manier om erachter te komen is het systeem vragen in plaats van aannemen, met getconf in een script of met sysconf() in code.

6.6 De standaardcompiler is een shell-script

POSIX legt een C-compiler vast als opdrachtregelprogramma. Tot 2024 heette dat c99, en jouw systeem heeft het:

$ ls -l /bin/c99
lrwxrwxrwx 1 root root 21 Nov 17  2020 /bin/c99 -> /etc/alternatives/c99
$ ls -l /usr/bin/c99-gcc
-rwxr-xr-x 1 root root 454 Nov 17  2020 /usr/bin/c99-gcc
$ head -10 /usr/bin/c99-gcc
#! /bin/sh

# Call the appropriate C compiler with options to accept ANSI/ISO C
# The following options are the same (as of gcc-3.3):
# 	-std=c99
# 	-std=c9x
# 	-std=iso9899:1999
# 	-std=iso9899:199x

extra_flag=-std=c99

De POSIX C-compiler op een Linux-systeem is een shell-script van 454 bytes dat -std=c99 toevoegt en GCC aanroept. Dat is het patroon voor een groot deel van de standaard: hij eist geen bepaalde implementatie, alleen een opdracht met een vastgelegde naam en vastgelegd gedrag. Alles wat aan de beschrijving voldoet is een implementatie die de standaard volgt, ook een omhulsel dat je bij een kop koffie uitleest. De herziening van 2024 heeft c99 met pensioen gestuurd en c17 in de plaats gezet.

6.7 De STANDARDS-sectie in handleidingen

Linux-handleidingen van functies hebben een STANDARDS-sectie die noemt uit welke standaard een interface komt, en dat is de snelste portabiliteitscontrole die er is:

$ man 2 open      # then look for STANDARDS: POSIX.1-2008
$ man 3 strdup    # POSIX.1-2008; before that, a common extension
$ man 2 epoll_create  # STANDARDS: Linux only

"Linux" in die sectie betekent dat de code die je schrijft niet compileert op een BSD of op macOS. "POSIX.1-2008" betekent dat hij overal werkt. Oudere pagina's noemen dit CONFORMING TO, wat dezelfde informatie onder een andere kop is.

6.8 Waar Linux verder gaat dan de standaard

Die sectie is het nuttigst wanneer twee interfaces hetzelfde werk doen en er maar één portabel is. Wachten op activiteit op veel file descriptors tegelijk is het duidelijkste geval:

$ man 2 select      # STANDARDS: POSIX.1-2008
$ man 2 poll        # STANDARDS: POSIX.1-2008
$ man 7 epoll       # STANDARDS: Linux
$ man 2 signalfd    # STANDARDS: Linux
$ man 7 inotify     # STANDARDS: Linux

select() en poll() staan in de standaard en werken op elke Unix. epoll is alleen Linux, en het bestaat omdat die twee slecht schalen zodra je duizenden descriptors in de gaten houdt: ze geven de kernel bij elke aanroep de hele lijst mee. Hetzelfde patroon herhaalt zich met inotify voor bestandswijzigingen, met eventfd en signalfd, en met het nieuwere io_uring. Elk daarvan is een Linux-antwoord op een echte beperking van de portabele interface.

Dat is een afweging, geen fout. Een portabele bibliotheek houdt het bij poll(). Een server die toch alleen op Linux gaat draaien gebruikt epoll en zegt dat erbij. Wat misgaat is kiezen zonder het te merken, en dat is precies wat de STANDARDS-sectie voorkomt.

Dezelfde tweedeling bestaat buiten C. /proc is een Linux-uitvinding en staat in geen enkele standaard, dus elk script dat /proc/$$/fd of /proc/meminfo leest is alleen-Linux, hoe gewoon het er ook uitziet. Op een server die je zelf beheert is dat meestal prima. Het is handig om te weten voordat iemand het script op een Mac draait.

8. Beste werkwijzen

• Laat de shebang passen bij de taal die je hebt geschreven. #!/bin/bash als je Bash-functies gebruikt, #!/bin/sh alleen als je binnen de standaard bent gebleven. Allebei zijn goed; de verkeerde claimen is de fout.
• Test sh-scripts onder een strenge shell. dash -n script.sh duurt twee seconden en vangt elke bashism op syntaxniveau. Zet het in je Makefile of CI-taak, naast shellcheck.
• Gebruik printf en niet echo zodra er escapes of opties in het spel zijn. Het gedrag van echo met -n en backslashes is implementation-defined, en twee shells op één machine zijn het al oneens.
• Gebruik command -v om te testen of een opdracht bestaat. which is geen standaard, verschilt per distributie, en ziet geen builtins of functies.
• Quote elke variabele, en houd bestandsnamen in de portabele tekenset. "$file" kost twee tekens. pathchk -p vertelt je welke namen elders problemen geven.
• Vraag het systeem naar limieten in plaats van ze vast in te typen. getconf in scripts, sysconf() en pathconf() in C. De _POSIX_-constanten zijn gegarandeerde minima, niet de waarden van jouw machine.
• Zet expliciet de feature test macro die je code nodig heeft. -D_POSIX_C_SOURCE=200809L legt vast tegen welke standaard je hebt geschreven en voorkomt dat een strengere bouwvlag de halve C-bibliotheek verstopt.
• Noem de versie als je "POSIX" zegt. "POSIX.1-2008" is een feit. "POSIX compliant" is een gevoel, en de twee systemen in de discussie hebben waarschijnlijk allebei gelijk.
• Zet POSIXLY_CORRECT niet globaal. Gebruik het per opdracht om te zien hoe een streng systeem zich zou gedragen, en haal het daarna weg. Het verandert veel programma's tegelijk.
• Lees de documentatie. Alles staat er al, of is één pakket weg:

$ man 7 standards            # every standard, with dates and lineage
$ man 7 posixoptions         # the optional units of the standard
$ man 7 feature_test_macros  # which macro exposes which interfaces
$ getconf -a                 # what this system reports about itself
$ man 1p sh                  # the standard itself, after installing manpages-posix

De volledige tekst is gratis te lezen op pubs.opengroup.org, en dat is de enige bron die een discussie beslecht.

10. Samenvatting

POSIX is het geschreven contract tussen programma's en de systemen waarop ze draaien: een document, uitgegeven door IEEE en The Open Group, dat zegt wat een Unix-achtig systeem moet leveren. Het is de reden dat een shell-script uit 1995 nog draait, dat man 1p en man 1 verschillende pagina's zijn, en dat de discussie of een machine "fout" is meestal een antwoord heeft dat je kunt aanhalen.

• POSIX is een standaarddocument, geen software. Systemen implementeren het; certificering is een apart commercieel traject, en Linux koopt dat niet.
• De naam betekent Portable Operating System Interface. De X is een knipoog naar de Unix-naamgeving, en Richard Stallman bedacht de term.
• Het verschijnt in vier delen: definities, C-interfaces, shell en programma's, en de rationale. Eén document, ook bekend als IEEE 1003.1, ISO/IEC 9945 en de Single UNIX Specification.
• Het ontstond uit de splitsing tussen System V en BSD, werd in 2001 door de Austin Group samengevoegd met de Single UNIX Specification, en werd na zestien jaar rust herzien als POSIX.1-2024.
• getconf beantwoordt vragen over je eigen systeem: _POSIX_VERSION, het standaard-PATH, en de limieten achter foutmeldingen als "Argument list too long".
• #!/bin/sh belooft standaard shell-code. Op Debian en Ubuntu is die shell dash, en dash -n controleert die belofte in twee seconden.
• De gebruikelijke bashisms - [[ ]], arrays, ${x^^}, source, echo -e - hebben allemaal een standaardequivalent, en printf vervangt echo zodra er een escape in zit.
• Vier woorden dragen de hele belofte: defined, implementation-defined, unspecified, undefined. In de middelste twee zitten de portabiliteitsfouten.
• Op Linux levert de C-bibliotheek POSIX, niet de kernel. Een programma dat fork() aanroept bereikt de kernel als clone(), en conformiteit hoort bij de hele distributie en niet bij Linux zelf.
• In C bepalen feature test macro's welke functies de headers laten zien. -D_POSIX_C_SOURCE=200809L is het verschil tussen "die functie bestaat niet" en een schone build.
• Standaardfuncties melden een fout via een retourwaarde plus errno. Lees hem alleen na een fout, en lees hem meteen: de volgende bibliotheekaanroep kan hem overschrijven.
• POSIX is een API-standaard en geen ABI-standaard: portabele broncode, per systeem opnieuw gecompileerd. Uitvoerbare formaten en nummers van systeemaanroepen vallen erbuiten, en select() is portabel waar epoll alleen Linux is.
• Vraag limieten tijdens het draaien op met sysconf() en pathconf(). De _POSIX_-constanten zijn minima, geen metingen.
• Het standaard-archiefprogramma is pax, en dat is niet geïnstalleerd. POSIX-ACL's komen uit een opgegeven concept. Twee gecertificeerde UNIX-systemen zijn Linux-distributies.
• bash --posix is geen portabiliteitscontrole, en dat iets in de nieuwste standaard staat betekent niet dat de shell voor je neus het al heeft.

Dit is het spiekbriefje dat het bewaren waard is:

getconf _POSIX_VERSION       which edition this system implements
getconf _XOPEN_VERSION       which Single UNIX Specification issue
getconf -a                   every value the system reports
getconf PATH                 the standard PATH for finding utilities
getconf ARG_MAX              the limit behind "Argument list too long"
command -p -v NAME           find a command using the standard PATH
command -v NAME              portable test that a command exists
pathchk -p NAME              is this filename portable
dash -n script.sh            parse a script with a strict POSIX shell
POSIXLY_CORRECT=1 cmd        run one command as a strict system would
printf 'a\tb\n'              portable output; echo escapes are implementation-defined
man 7 standards              every standard, with dates and lineage
man 7 posixoptions           the optional units of the standard
man 7 feature_test_macros    which macro exposes which C interfaces
man 2 poll / man 7 epoll     a portable interface versus a Linux-only one
strace -e trace=clone ./prog which system call a POSIX function becomes
man 1p sh / man 3p open      the standard's own manual pages
gcc -D_POSIX_C_SOURCE=200809L  expose POSIX.1-2008 in the headers

En als een script drie jaar lang onaangeroerd heeft gedraaid en dan faalt in de week dat een server opnieuw is opgebouwd, is de code zelden wat er is veranderd: iets eronder is opgehouden het systeem te zijn dat het script stilzwijgend aannam, en in de standaard vind je wie van de twee zat te verzinnen.