POSIX.1-2017 is simultaneously IEEE Std 1003.1™-2017 and The Open Group Technical Standard Base Specifications, Issue 7.
This introduction is not part of IEEE Std 1003.1-2017, Standard for Information Technology – Portable Operating System Interface (POSIX).
This standard was developed, and is maintained, by a joint working group of members of the IEEE Portable Applications Standards Committee, members of The Open Group, and members of ISO/IEC Joint Technical Committee 1. This joint working group is known as the Austin Group.B
The Austin Group arose out of discussions amongst the parties which started in early 1998, leading to an initial meeting and formation of the group in September 1998. The purpose of the Austin Group is to develop and maintain the core open systems interfaces that are the POSIX® 1003.1 (and former 1003.2) standards, ISO/IEC 9945, and the core of the Single UNIX Specification.
The approach to specification development has been one of “write once, adopt everywhere”, with the deliverables being a set of specifications that carry the IEEE POSIX designation, The Open Group's Technical Standard designation, and an ISO/IEC designation.
This unique development has combined both the industry-led efforts and the formal standardization activities into a single initiative, and included a wide spectrum of participants. The Austin Group continues as the maintenance body for this document.
Anyone wishing to participate in the Austin Group should contact the chair with their request. There are no fees for participation or membership. You may participate as an observer or as a contributor. You do not have to attend face-to-face meetings to participate; electronic participation is most welcome. For more information on the Austin Group and how to participate, see www.opengroup.org/austin.
The developers of POSIX.1-2017 represent a cross-section of hardware manufacturers, vendors of operating systems and other software development tools, software designers, consultants, academics, authors, applications programmers, and others.
Conceptually, POSIX.1-2017 describes a set of fundamental services needed for the efficient construction of application programs. Access to these services has been provided by defining an interface, using the C programming language, a command interpreter, and common utility programs that establish standard semantics and syntax. Since this interface enables application developers to write portable applications – it was developed with that goal in mind – it has been designated POSIXC, an acronym for Portable Operating System Interface.
Although originated to refer to the original IEEE Std 1003.1-1988, the name POSIX more correctly refers to a family of related standards: IEEE Std 1003.n and the parts of ISO/IEC 9945. In earlier editions of the IEEE standard, the term POSIX was used as a synonym for IEEE Std 1003.1-1988. A preferred term, POSIX.1, emerged. This maintained the advantages of readability of the symbol “POSIX” without being ambiguous with the POSIX family of standards.
The intended audience for POSIX.1-2017 is all persons concerned with an industry-wide standard operating system based on the UNIX system. This includes at least four groups of people:
Persons buying hardware and software systems
Persons managing companies that are deciding on future corporate computing directions
Persons implementing operating systems, and especially
Persons developing applications where portability is an objective
Purpose
Several principles guided the development of POSIX.1-2017:
Application-Oriented – The basic goal was to promote portability of application programs across UNIX system environments by developing a clear, consistent, and unambiguous standard for the interface specification of a portable operating system based on the UNIX system documentation. POSIX.1-2017 codifies the common, existing definition of the UNIX system.
Interface, Not Implementation – POSIX.1-2017 defines an interface, not an implementation. No distinction is made between library functions and system calls; both are referred to as functions. No details of the implementation of any function are given (although historical practice is sometimes indicated in the RATIONALE section). Symbolic names are given for constants (such as signals and error numbers) rather than numbers.
Source, Not Object, Portability – POSIX.1-2017 has been written so that a program written and translated for execution on one conforming implementation may also be translated for execution on another conforming implementation. POSIX.1-2017 does not guarantee that executable (object or binary) code will execute under a different conforming implementation than that for which it was translated, even if the underlying hardware is identical.
The C Language – The system interfaces and header definitions are written in terms of the standard C language as specified in the ISO C standard.
No Superuser, No System Administration – There was no intention to specify all aspects of an operating system. System administration facilities and functions are excluded from this standard, and functions usable only by the superuser have not been included. Still, an implementation of the standard interface may also implement features not in POSIX.1-2017. POSIX.1-2017 is also not concerned with hardware constraints or system maintenance.
Minimal Interface, Minimally Defined – In keeping with the historical design principles of the UNIX system, the mandatory core facilities of POSIX.1-2017 have been kept as minimal as possible. Additional capabilities have been added as optional extensions.
Broadly Implementable – The developers of POSIX.1-2017 endeavored to make all specified functions implementable across a wide range of existing and potential systems, including:
All of the current major systems that are ultimately derived from the original UNIX system code (Version 7 or later)
Compatible systems that are not derived from the original UNIX system code
Emulations hosted on entirely different operating systems
Networked systems
Distributed systems
Systems running on a broad range of hardware
No direct references to this goal appear in POSIX.1-2017, but some results of it are mentioned in the Rationale (Informative) volume.
Minimal Changes to Historical Implementations – When the original version – IEEE Std 1003.1-1988 – was published, there were no known historical implementations that did not have to change. However, there was a broad consensus on a set of functions, types, definitions, and concepts that formed an interface that was common to most historical implementations.
The adoption of the 1988 and 1990 IEEE system interface standards, the 1992 IEEE shell and utilities standard, the various Open Group (formerly X/Open) specifications, and IEEE Std 1003.1-2001 and its technical corrigenda have consolidated this consensus, and this version reflects the significantly increased level of consensus arrived at since the original versions. The authors of the original versions tried, as much as possible, to follow the principles below when creating new specifications:
By standardizing an interface like one in an historical implementation; for example, directories
By specifying an interface that is readily implementable in terms of, and backwards-compatible with, historical implementations, such as the extended tar format defined in the pax utility
By specifying an interface that, when added to an historical implementation, will not conflict with it; for example, the sigaction() function
POSIX.1-2017 is specifically not a codification of a particular vendor's product.
It should be noted that implementations will have different kinds of extensions. Some will reflect “historical usage” and will be preserved for execution of pre-existing applications. These functions should be considered “obsolescent” and the standard functions used for new applications. Some extensions will represent functions beyond the scope of POSIX.1-2017. These need to be used with careful management to be able to adapt to future extensions of POSIX.1-2017 and/or port to implementations that provide these services in a different manner.
Minimal Changes to Existing Application Code – A goal of POSIX.1-2017 was to minimize additional work for application developers. However, because every known historical implementation will have to change at least slightly to conform, some applications will have to change.
POSIX.1-2017 defines the Portable Operating System Interface (POSIX) requirements and consists of the following topics arranged as a series of volumes within the standard:
Base Definitions
System Interfaces
Shell and Utilities
Rationale (Informative)
The Base Definitions volume provides common definitions for this standard, therefore readers should be familiar with it before using the other volumes.
This volume is structured as follows:
Chapter 1 is an introduction.
Chapter 2 defines the conformance requirements.
Chapter 3 defines general terms used.
Chapter 4 describes general concepts used.
Chapter 5 describes the notation used to specify file input and output formats in this volume and the Shell and Utilities volume.
Chapter 6 describes the portable character set and the process of character set definition.
Chapter 7 describes the syntax for defining internationalization locales as well as the POSIX locale provided on all systems.
Chapter 8 describes the use of environment variables for internationalization and other purposes.
Chapter 9 describes the syntax of pattern matching using regular expressions employed by many utilities and matched by the regcomp() and regexec() functions.
Chapter 10 describes files and devices found on all systems.
Chapter 11 describes the asynchronous terminal interface for many of the functions in the System Interfaces volume and the stty utility in the Shell and Utilities volume.
Chapter 12 describes the policies for command line argument construction and parsing.
Chapter 13 defines the contents of headers which declare the functions and global variables, and define types, constants, macros, and data structures that are needed by programs using the services provided by the System Interfaces volume.
Comprehensive references are available in the index.
The System Interfaces volume describes the interfaces offered to application programs by POSIX-conformant systems. Readers are expected to be experienced C language programmers, and to be familiar with the Base Definitions volume.
This volume is structured as follows:
Chapter 1 explains the status of this volume and its relationship to other formal standards.
Chapter 2 contains important concepts, terms, and caveats relating to the rest of this volume.
Chapter 3 defines the functional interfaces to the POSIX-conformant system.
Comprehensive references are available in the index.
The Shell and Utilities volume describes the commands and utilities offered to application programs on POSIX-conformant systems. Readers are expected to be familiar with the Base Definitions volume.
This volume is structured as follows:
Chapter 1 explains the status of this volume and its relationship to other formal standards. It also describes the defaults used by the utility descriptions.
Chapter 2 describes the command language used in POSIX-conformant systems, and special built-in utilities.
Chapter 3 describes a set of services and utilities that are implemented on systems supporting the Batch Environment Services and Utilities option.
Chapter 4 consists of reference pages for all utilities, other than the special built-in utilities described in Chapter 2, available on POSIX-conformant systems.
Comprehensive references are available in the index.
The Rationale volume is published to assist in the process of review. It contains historical information concerning the contents of this standard and why features were included or discarded by the standard developers. It also contains notes of interest to application programmers on recommended programming practices, emphasizing the consequences of some aspects of POSIX.1-2017 that may not be immediately apparent.
This volume is organized in parallel to the normative volumes of this standard, with a separate part for each of the three normative volumes.
Within this volume, the following terms are used:
Base standard – The portions of POSIX.1-2017 that are not optional, equivalent to the definitions of classic POSIX.1 and POSIX.2.
POSIX.0 – Although this term is not used in the normative text of POSIX.1-2017, it is used in this volume to refer to IEEE Std 1003.0™-1995.
POSIX.1b – Although this term is not used in the normative text of POSIX.1-2017, it is used in this volume to refer to the elements of the POSIX Realtime Extension amendment. (This was earlier referred to as POSIX.4 during the standard development process.)
POSIX.1c – Although this term is not used in the normative text of POSIX.1-2017, it is used in this volume to refer to the POSIX Threads Extension amendment. (This was earlier referred to as POSIX.4a during the standard development process.)
Standard developers – The individuals and companies in the development organizations responsible for POSIX.1-2017: the IEEE P1003.1 working groups, The Open Group Base working group, advised by the hundreds of individual technical experts who balloted the draft standards within the Austin Group, and the member bodies and technical experts of ISO/IEC JTC 1/SC 22.
XSI option – The portions of POSIX.1-2017 addressing the extension added for support of the Single UNIX Specification.
B The Austin Group is named after the location of the inaugural meeting held at the IBM facility in Austin, Texas in September 1998.
C The Name POSIX was suggested by Richard Stallman. It is expected to be pronounced pahz-icks, as in positive, not poh-six, or other variations. The pronunciation has been published in an attempt to promulgate a standardized way of referring to a standard operating system interface.