Linux concept: POSIX

A script works on your laptop. You copy it to the server, it runs from cron at three in the morning, and it fails on a line that has not changed. Nobody edited it, no package was upgraded, and the same file still works when you run it by hand. The usual cause is not a bug in your logic. It is that the two machines disagree about what a Unix system is, and the document that decides who is right is called POSIX.

This article explains what POSIX actually is, where the name comes from, how forty years of Unix arguments produced it, and how to use it: asking your own system which version it implements, reading the standard for free, writing shell scripts that survive a move to another machine, and the feature test macros that decide which functions your C compiler will admit exist. On the way it separates the C library from the kernel, and source portability from binary compatibility. It also covers what POSIX is not, which is where most of the confusion lives.

If you only write shell scripts, you can skip section 6: it is for readers who write or compile C, and the rest of the article does not depend on it.

From "why did my script break on the server" to "which of these two systems is wrong".

The goal: after reading this you can look at any portability problem and say whether the standard has an opinion about it.

2. Where the Name Comes From

POSIX stands for Portable Operating System Interface. Read the words in order and they describe the whole project: an interface to an operating system, specified so that software is portable between systems that provide it.

The last letter does not come from the words. There is no X in "Portable Operating System Interface", and the standard ends in one because of a naming habit: Unix systems of the era were called AIX, IRIX, HP-UX, Ultrix, Xenix, and an X at the end read as "this belongs to the Unix family". The name is deliberately pronounceable, and it stuck immediately.

The person who suggested it is recorded in the Linux manual pages. Run man 7 standards and read the entry for the first edition:

$ 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.

The IEEE working group needed a name for a document that was, until then, known only by its committee number. The number never went away, which is why you meet the same standard under several names at once:

A letter after the number means an amendment rather than a new edition. POSIX.1b added real-time facilities in 1993 and POSIX.1c added threads in 1995, and both were later folded into the main document. When you see 1003.1c in a manual page, it is telling you that a function arrived with the threads amendment.

The picture the name describes is a single line drawn through a running system:

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

Everything above the line is yours. Everything below it is the implementation's business, and the standard says nothing about how it is done. POSIX never mentions inodes on disk, scheduling algorithms, or how a filesystem is laid out. It only fixes what the layer looks like from above, which is exactly what a program needs to know and nothing more.

4. Simple Use Cases: POSIX at Your Prompt

POSIX sounds like something only standards committees touch. In fact your system ships several tools whose only job is to answer questions about it, and they are worth knowing before you need them.

4.1 Asking the System What It Provides

getconf without arguments reports one value; with -a (short for all) it dumps everything the system knows. Filtering that dump is the quickest way to see which optional parts of the standard are present:

$ 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

Read those values as answers to yes-or-no questions. A date means "this optional feature is present, at this edition of the standard". A 1 means "present", an empty value means "not supported here". Threads, timers and posix_spawn() are all optional units in the text of the standard, even though every general-purpose system has had them for twenty years.

The same tool reports the system's limits, which are more useful than they look:

$ 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 the number behind the error "Argument list too long", and it is why find ... -exec cmd {} + and xargs exist. NAME_MAX and PATH_MAX take a path argument because the answer depends on the filesystem mounted there, not on the system as a whole.

4.2 The Standard PATH

POSIX defines a PATH value that is guaranteed to find the standard utilities, and getconf will hand it to you:

$ getconf PATH
/bin:/usr/bin

This is the value to use when a script must not depend on whatever PATH it inherited. The shell has a matching tool: command -p (short for path) looks the command up in exactly that standard PATH, ignoring yours:

$ command -p -v ls
/bin/ls

That matters in a cron job, a systemd unit, or anything running under sudo, where the PATH is not the one you tested with. If a script works at your prompt and fails from cron with "command not found", the PATH is the first thing to check, and command -p is the portable way to stop caring.

4.3 Reading the Standard Itself

The standard is not a secret document behind a paywall. The Open Group publishes the full text as HTML for free at pubs.opengroup.org, and it is the authority worth citing in any argument about portability. It is also readable: each utility page has the same layout, with SYNOPSIS, OPTIONS, an EXAMPLES section, and a RATIONALE explaining why the committee chose what it did.

You can also read it as manual pages. The POSIX text ships as its own manual sections, where 1p is utilities and 3p is functions:

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

Those pages are a separate package, because the standard's licence is not free enough for the main archives. On Debian and Ubuntu it sits 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()

The difference between man 1 ls and man 1p ls is precisely the difference this article is about. The first tells you what your ls does. The second tells you what every ls must do. When they disagree, the extra behaviour is a local extension, and using it is a decision rather than an accident.

Two more pages are worth bookmarking, and both are already installed:

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

4.4 Checking a Filename Is Portable

POSIX defines a portable filename character set: letters, digits, dot, underscore and hyphen. The pathchk utility checks names against it, with -p for 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

Silence means the name is safe. This is not about what Linux accepts, which is nearly any byte except / and NUL. It is about what survives a trip through another system, an archive format, or a script that forgot to quote a variable.

-p checks the length against the standard as well, and the standard is stricter than any system you have used this century:

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

Fourteen characters is the floor POSIX guarantees for one filename component, a number inherited from early Unix filesystems. Your filesystem allows 255, which is why nobody hits this. It is a good illustration of what -p means: not "will this work here", but "will this work on the smallest system the standard still permits".

6. Advanced Use Cases: POSIX in C

The other half of the standard is the C interface, and it decides something that surprises people the first time they meet it: which functions your compiler will admit exist.

If you never compile C yourself, skip ahead to section 7. Nothing there builds on this section, and the C items in the later lists are short recaps of what follows here.

6.1 The C Library Is the Layer, Not the Kernel

POSIX describes an interface for programs, and on Linux that interface is provided by the C library, not by the kernel. Your program calls a standard function; the C library decides what to ask the kernel for:

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

Those two middle layers are not the same list, and one command shows it. POSIX defines fork(). Linux does have a fork system call, and glibc does not use it: it creates the child with clone() instead, because that one call covers processes and threads together.

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

The program called fork(). The kernel was asked for clone(). Nothing is broken: a POSIX function is a promise about behaviour, not a name for a system call. Some functions are thin wrappers, some are built out of a different call, and parts of pthread live mostly in the library.

Two consequences follow. POSIX says nothing about which system calls exist or how they are numbered, so the kernel is free to change how a function is implemented as long as the function keeps behaving as specified. And conformance is a property of a whole system - kernel, C library, shell and utilities together - which is why "is Linux POSIX?" has no clean answer. Linux is the kernel. The thing that implements POSIX is the distribution.

6.2 Feature Test Macros

Here is a program that uses strdup(), a function that has been in POSIX since 2008 and in every C library for far longer:

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

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

Compile it as strict C99 and the compiler says the function does not exist:

$ 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'?

Nothing is missing from your system. strdup() is in the C library, and the linker will find it. What happened is that -std=c99 asked for the ISO C language and nothing more, and strdup() is not in ISO C: it is POSIX. So the header hid it.

The switch that unhides it is a feature test macro, defined before any header is included, or on the command line:

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

The number is the same date encoding as before: ask for the 2008 edition, get everything the 2008 edition defines. Ask for 199309L and you get the smaller set the 1993 amendment defined. The macros are a way of saying which standard you are writing against, and the headers show you exactly that much:

This is why the same source file compiles on your laptop and fails in a container with a stricter build flag, and why manual pages carry a line in the SYNOPSIS telling you which macro a function needs. man 7 feature_test_macros is the complete reference, and it is one of the most useful pages on the system.

The mapping is visible in the headers themselves:

$ 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

Five definitions in one file, inside a chain of #if branches. Whichever macro you asked for picks one of them, and your program then sees the version of the interface that goes with it.

6.3 How POSIX Functions Report Failure

Nearly every function in the standard reports trouble the same way: a return value saying that something went wrong, and the variable errno saying what. The standard defines the error names, which is why ENOENT means the same thing on Linux, on macOS and on 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

Two rules come with errno, and both are in the standard rather than in folklore. First, only read it after a call has told you it failed. A successful call is allowed to change it, and nothing resets it to zero for you, so a stale value from an earlier call is the usual reason an error message names the wrong problem. Second, read it immediately: any library call in between, printf() included, may overwrite it. That is why the example copies it into saved before doing anything else.

The error worth knowing by name is EINTR. A blocking call interrupted by a signal can return with it instead of finishing, so portable code has to decide whether to retry. man 7 signal is the reference, and it also names a place where Linux goes past the standard: a blocking call here can fail with EINTR after the process is stopped and resumed, which the page says "is not sanctioned by POSIX.1, and doesn't occur on other systems".

6.4 Asking at Compile Time and at Run Time

The same question has two answers, and mixing them up is a real bug. A program can read the compile-time constant from <unistd.h>:

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

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

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

That is what the headers on the build machine said. To ask the machine the program is actually running on, use the run-time functions: sysconf() for system-wide values, pathconf() and fpathconf() for values that depend on a filesystem, and confstr() for string values such as the standard PATH. getconf from section 4.1 is a thin wrapper around exactly these three.

The distinction matters for limits. The constants whose names start with _POSIX_ are the minimum the standard guarantees, not the size of anything on your machine. The two numbers are not close:

$ 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

A conforming system must allow a filename component of 14 characters and a path of 256. This one allows 255 and 4096. Write for the floor if your code must run anywhere, but never compile either number into a buffer size: ask at run time, on the path you are about to use, because the answer differs between a local ext4 mount and a network share on the same system.

6.5 The Optional Parts

Not everything in POSIX is mandatory. Whole areas are optional units that a conforming system may leave out, and each one has a macro to test for it. Threads, real-time signals, message queues, asynchronous I/O and shared memory are all in this category:

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

On a general-purpose Linux system nearly all of them are present, which is why this rarely bites. It matters when your target is smaller: an embedded system, a minimal container image with musl instead of glibc, or a real-time variant. The correct way to find out is to ask the system rather than to assume, either with getconf in a script or with sysconf() in code.

6.6 The Standard Compiler Is a Shell Script

POSIX standardises a C compiler as a command-line utility. Until 2024 it was called c99, and your system has it:

$ 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

The POSIX C compiler on a Linux system is a 454-byte shell script that adds -std=c99 and calls GCC. This is the pattern for a great deal of the standard: it does not require a particular implementation, only a command with a specified name and specified behaviour. Anything that satisfies the description is a conforming implementation, including a wrapper you could read over a coffee. The 2024 revision retired c99 and standardised c17 in its place.

6.7 The STANDARDS Section in Manual Pages

Linux manual pages for functions carry a STANDARDS section that names the standard an interface comes from, and it is the fastest portability check available:

$ 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 that section means the code you are writing will not compile on a BSD or on macOS. "POSIX.1-2008" means it will work anywhere. Older pages phrase this as CONFORMING TO instead, which is the same information under a different heading.

6.8 Where Linux Goes Past the Standard

That section is most useful when two interfaces do the same job and only one of them is portable. Waiting for activity on many file descriptors at once is the clearest case:

$ 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() and poll() are in the standard and work on any Unix. epoll is Linux only, and it exists because those two scale badly once you are watching thousands of descriptors: they hand the kernel the whole list on every call. The same pattern repeats with inotify for file changes, with eventfd and signalfd, and with the newer io_uring. Each is a Linux answer to a real limit in the portable interface.

That is a trade, not a mistake. A portable library sticks to poll(). A server that will only ever run on Linux uses epoll and says so. What goes wrong is choosing without noticing, which is exactly what the STANDARDS section prevents.

The same split exists outside C. /proc is a Linux invention and appears in no standard, so every script that reads /proc/$$/fd or /proc/meminfo is Linux-only, however ordinary it looks. That is usually fine on a server you control. It is worth knowing before someone runs the script on a Mac.

8. Best Practices

• Match the shebang to the language you wrote. #!/bin/bash if you use Bash features, #!/bin/sh only if you stayed inside the standard. Both are correct; claiming the wrong one is the bug.
• Test sh scripts under a strict shell. dash -n script.sh takes two seconds and catches every syntax-level bashism. Put it in your Makefile or CI job next to shellcheck.
• Use printf, not echo, whenever escapes or options are involved. echo's behaviour with -n and backslashes is implementation-defined, and two shells on one machine already disagree.
• Use command -v to test whether a command exists. which is not standard, varies between distributions, and cannot see builtins or functions.
• Quote every variable, and keep filenames in the portable character set. "$file" costs two characters. pathchk -p tells you which names will cause trouble elsewhere.
• Ask the system for limits instead of hard-coding them. getconf in scripts, sysconf() and pathconf() in C. The _POSIX_ constants are guaranteed minimums, not your machine's values.
• Set the feature test macro your code needs, explicitly. -D_POSIX_C_SOURCE=200809L documents which standard you wrote against and stops a stricter build flag from hiding half the C library.
• Name the version when you say "POSIX". "POSIX.1-2008" is a fact. "POSIX compliant" is a feeling, and the two systems in the argument are probably both right.
• Do not set POSIXLY_CORRECT globally. Use it per command to see how a strict system would behave, then take it off. It changes many programs at once.
• Read the documentation. It is all installed, or one package away:

$ 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

The full text is free to read at pubs.opengroup.org, and it is the only source that settles an argument.

10. Summary

POSIX is the written contract between programs and the systems they run on: a document, published by IEEE and The Open Group, that says what a Unix-like system must provide. It is why a shell script from 1995 still runs, why man 1p and man 1 are different pages, and why the argument about whether a machine is "wrong" usually has a citable answer.

• POSIX is a standard document, not software. Systems implement it; certification is a separate commercial process, and Linux does not buy it.
• The name means Portable Operating System Interface. The X is a nod to Unix naming, and Richard Stallman coined the term.
• It is published in four volumes: definitions, C interfaces, shell and utilities, and rationale. One document also known as IEEE 1003.1, ISO/IEC 9945, and the Single UNIX Specification.
• It grew out of the split between System V and BSD, was unified with the Single UNIX Specification by the Austin Group in 2001, and was revised as POSIX.1-2024 after sixteen years of stability.
• getconf answers questions about your own system: _POSIX_VERSION, the standard PATH, and the limits behind errors like "Argument list too long".
• #!/bin/sh promises standard shell code. On Debian and Ubuntu that shell is dash, and dash -n checks the promise in two seconds.
• The usual bashisms - [[ ]], arrays, ${x^^}, source, echo -e - all have standard equivalents, and printf replaces echo for anything with an escape in it.
• Four words carry the whole promise: defined, implementation-defined, unspecified, undefined. The middle two are where portability bugs live.
• On Linux the C library provides POSIX, not the kernel. A program that calls fork() reaches the kernel as clone(), and conformance belongs to the whole distribution rather than to Linux itself.
• In C, feature test macros decide which functions the headers expose. -D_POSIX_C_SOURCE=200809L is the difference between "no such function" and a clean build.
• Standard functions report failure through a return value plus errno. Read it only after a failure, and read it immediately: the next library call may overwrite it.
• POSIX is an API standard, not an ABI one: portable source, recompiled per system. Executable formats and system call numbers are outside it, and select() is portable where epoll is Linux only.
• Ask for limits at run time with sysconf() and pathconf(). The _POSIX_ constants are minimums, not measurements.
• The standard archiver is pax, which is not installed. POSIX ACLs come from an abandoned draft. Two certified UNIX systems are Linux distributions.
• bash --posix is not a portability check, and something being in the newest standard does not mean the shell in front of you has it yet.

This is the quick reference worth keeping:

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

And when a script has run untouched for three years and then fails the week a server is rebuilt, the code is rarely what changed: something underneath it stopped being the system the script quietly assumed, and the standard is where you find out which of the two was making things up.