| Portable Operating System Interface (IEEE 1003) | |
|---|---|
| Abbreviation | POSIX |
| Status | Published |
| Year started | 1988 |
| Latest version | IEEE Std 1003.1-2024 2024 |
| Organization | Austin Group (IEEE Computer Society, The Open Group, ISO/IEC JTC 1/SC 22/WG 15) |
| Related standards | ISO/IEC 9945 |
| Domain | Application programming interfaces |
| Website | posix |
The Portable Operating System Interface (POSIX; IPA: /ˈpɒz.ɪks/ [1] ) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems. [1] In order to define a level of compatibility, POSIX specifies many aspects of functionality that can be classified as application programming interface (API), command-line shell, and shell commands. Originally derived from commonly-found Unix APIs, shells, and commands (partly because Unix was considered manufacturer-neutral), today many systems conform to the standard – including branded Unix systems, Unix-like systems, and many systems that were historically unrelated to Unix. [1] [2]
The standardized user command line and scripting interface were based on the UNIX System V Bourne shell. [3] Many user-level programs, services, and utilities (including awk, echo, ed) were also standardized, based on UNIX System V versions of them, along with required program-level services (including basic I/O: file, terminal, and network). POSIX also defines a standard threading library API which is supported by most modern operating systems.
The POSIX standard is developed by the Austin Group (a joint working group among the IEEE, The Open Group, and the ISO/IEC JTC 1/SC 22/WG 15).
POSIX is intended to be used by both application and system developers. [4] [ further explanation needed ]
The standards emerged from a project that began in 1984 building on work from related activity in the /usr/group association. [5] Richard Stallman suggested the name POSIX to the IEEE [6] [7] instead of the former IEEE-IX. [8] The committee found it more easily pronounceable and memorable, and thus adopted it.[ citation needed ]
Originally, POSIX referred to IEEE Std 1003.1-1988, released in 1988. The family of POSIX standards is formally designated as IEEE 1003 and the ISO/IEC standard number is ISO/IEC 9945.
POSIX originally consisted of a single document for core services but over time additional documents were published to extend and revise the specification. Before 1997, POSIX comprised multiple documents that were published over the course of several years. After 1997, the Austin Group produces specifications titled Single UNIX Specification (SUS). Over time, the group publishes versions of this specification and later POSIX is amended per some or all of a SUS version. A SUS version consists of a collection of volumes – each for a grouping of required behavior – plus other information (outside of a volume). [9] Each volume is assigned an issue number that is the same for each volume of a version, but is not the same value as the version. For example, SUS version 3 (SUSv3) includes volumes labeled issue 6.
As of 2014 [update] , POSIX documentation is divided into two parts:
Core Services (IEEE Std 1003.1-1988) incorporates standard ANSI C and includes:
Real-time extensions (IEEE Std 1003.1b-1993, later appearing as librt—the Realtime Extensions library) includes: [11]
Threads extensions (IEEE Std 1003.1c-1995) includes:
Shell and Utilities (IEEE Std 1003.2-1992) includes:
POSIX.1-2001 (IEEE Std 1003.1-2001) consists of most of SUSv3 which consists of volumes (issue 6): Base Definitions, System Interfaces and Headers, and Commands and Utilities. The POSIX specification specifically excludes the SUSv3 requirements for a curses API (often called X/Open Curses, even though there is no distinct grouping of this in SUSv3). [12]
IEEE Std 1003.1-2004 modifies POSIX.1-2001 via two minor updates or errata referred to as technical corrigenda documents. [13] [14]
Similar to its predecessor, POSIX.1-2008 (IEEE Std 1003.1-2008, 2016 Edition) consists of most of the normative material of SUSv4 (issue 7 of volumes Base Definitions, System Interfaces and Headers, Commands and Utilities). [15] SUSv4 also includes rationale information that largely applies to POSIX although not included per se.
POSIX.1-2017 (IEEE Std 1003.1-2017) revises the previous version (POSIX.1-2008) via two technical corrigenda. [16]
POSIX.1-2024 (IEEE Std 1003.1-2024) was published on 14 June 2024. [15] [17]
As of POSIX 2024, the standard is aligned with the C17 language standard.
POSIX mandates 512-byte default block sizes for the df and du utilities, reflecting the typical size of blocks on disks. When Richard Stallman and the GNU team were implementing POSIX for the GNU operating system, they objected to this on the grounds that most people think in terms of 1024 byte (or 1 KiB) blocks. The environment variable POSIX_ME_HARDER was introduced to allow the user to force the standards-compliant behaviour. [18] The variable name was later changed to POSIXLY_CORRECT. [19] As of 2025, this variable is also used for a number of other behaviour quirks. [20] [21] [22] [23] [24] [25] [26] [27] [28]
An operating system can be classified depending upon the degree of conformance with a POSIX standard.
Current versions of the following operating systems have been certified to conform to one or more of the various POSIX standards. This means that they passed the automated conformance tests [29] and their certification has not expired and the operating system has not been discontinued. [30] [31]
Some versions of the following operating systems had been certified to conform to one or more of the various POSIX standards. This means that they passed the automated conformance tests. The certification has expired and some of the operating systems have been discontinued. [30]
The following are not certified as POSIX conforming yet are considered partially conforming which is sometimes called compliant:[ citation needed ]
The following operating systems are not certified as POSIX conformant, but they conform in large part to the standard by implementing POSIX support via a compatibility feature (usually translation libraries, or a layer atop the kernel).
Some technologies allow an operating system to enjoy a level of conformance to POSIX even though the operating system itself has little or no conformance.
Although Windows does not conform to POSIX, the following technologies provide a level of compliance.
POSIX environments for OS/2:
POSIX environments for DOS include:
librt, libposix4- POSIX.1b Realtime Extensions library [...] librt is the preferred name for this library. The name libposix4 is maintained for backward compatibility and should be avoided. Functions in this library provide most of the interfaces specified by the POSIX.1b Realtime Extension.
If you want to build single codebase C++ code to run on Windows, Linux and MacOS, you need this for Windows