What is the meaning of "POSIX"?

What is POSIX? I have read the Wikipedia article and I read it every time I encounter the term. The fact is that I never really understood what it is.

Can anyone please explain it to me by explaining "the need for POSIX" too?

POSIX is a family of standards, specified by the IEEE, to clarify and make uniform the application programming interfaces (and ancillary issues, such as commandline shell utilities) provided by Unix-y operating systems.

When you write your programs to rely on POSIX standards, you can be pretty sure to be able to port them easily among a large family of Unix derivatives (including Linux, but not limited to it!); if and when you use some Linux API that's not standardized as part of Posix, you will have a harder time if and when you want to port that program or library to other Unix-y systems (e.g., MacOSX) in the future.

The most important things POSIX 7 defines

1. C API

   Greatly extends ANSI C with things like:

   • more file operations: mkdir, dirname, symlink, readlink, link (hardlinks), poll(), stat, sync, nftw()
   • process and threads: fork, execl, wait, pipe, semaphors sem_*, shared memory (shm_*), kill, scheduling parameters (nice, sched_*), sleep, mkfifo, setpgid()
   • networking: socket()
   • memory management: mmap, mlock, mprotect, madvise, brk()
   • utilities: regular expressions (reg*)

   Those APIs also determine underlying system concepts on which they depend, e.g. fork requires a concept of a process.

   Many Linux system calls exist to implement a specific POSIX C API function and make Linux compliant, e.g. sys_write, sys_read, ... Many of those syscalls also have Linux-specific extensions however.

   Major Linux desktop implementation: glibc, which in many cases just provides a shallow wrapper to system calls.

2. CLI utilities

   E.g.: cd, ls, echo, ...

   Many utilities are direct shell front ends for a corresponding C API function, e.g. mkdir.

   Major Linux desktop implementation: GNU Coreutils for the small ones, separate GNU projects for the big ones: sed, grep, awk, ... Some CLI utilities are implemented by Bash as built-ins.

3. Shell language

   E.g., a=b; echo "$a"

   Major Linux desktop implementation: GNU Bash.

4. Environment variables

   E.g.: HOME, PATH.

   PATH search semantics are specified, including how slashes prevent PATH search.

5. Program exit status

   ANSI C says 0 or EXIT_SUCCESS for success, EXIT_FAILURE for failure, and leaves the rest implementation defined.

   POSIX adds:

   • 126: command found but not executable.

   • 127: command not found.

   • > 128: terminated by a signal.

     But POSIX does not seem to specify the 128 + SIGNAL_ID rule used by Bash: <https://unix.stackexchange.com/questions/99112/default-exit-code-when-process-is-terminated>

   See also: What is the meaning of $? (dollar question mark) in shell scripts?

6. Regular expression

   There are two types: BRE (Basic) and ERE (Extended). Basic is deprecated and only kept to not break APIs.

   Those are implemented by C API functions, and used throughout CLI utilities, e.g. grep accepts BREs by default, and EREs with -E.

   E.g.: echo 'a.1' | grep -E 'a.[[:digit:]]'

   Major Linux implementation: glibc implements the functions under regex.h which programs like grep can use as backend.

7. Directory structure

   E.g.: /dev/null, /tmp

   The Linux FHS greatly extends POSIX.

8. Filenames

   • / is the path separator
   • NUL cannot be used
   • . is cwd, .. parent
   • portable filenames
     • use at most max 14 chars and 256 for the full path
     • can only contain: a-zA-Z0-9._-

   See also: <https://stackoverflow.com/questions/18550253/what-is-posix-compliance-for-filesystem>

9. Command line utility API conventions

   Not mandatory, used by POSIX, but almost nowhere else, notably not in GNU. But true, it is too restrictive, e.g. single letter flags only (e.g. -a), no double hyphen long versions (e.g. --all).

   A few widely used conventions:

   • - means stdin where a file is expected
   • -- terminates flags, e.g. ls -- -l to list a directory named -l

   See also: <https://stackoverflow.com/questions/8957222/are-there-standards-for-linux-command-line-switches-and-arguments>

10. "POSIX ACLs" (Access Control Lists), e.g. as used as backend for setfacl.

    This was withdrawn but it was implemented in several OSes, including in Linux with setxattr.

Who conforms to POSIX?

Many systems follow POSIX closely, but few are actually certified by the Open Group which maintains the standard. Notable certified ones include:

• OS X (Apple) X stands for both 10 and UNIX. Was the first Apple POSIX system, released circa 2001. See also: https://stackoverflow.com/questions/5785516/is-osx-a-posix-os
• AIX (IBM)
• HP-UX (HP)
• Solaris (Oracle)

Most Linux distros are very compliant, but not certified because they don't want to pay the compliance check. Inspur's K-UX and Huawei's EulerOS are two certified examples.

The official list of certified systems be found at: https://www.opengroup.org/openbrand/register/ and also at the wiki page.

Windows

Windows implemented POSIX on some of its professional distributions.

Since it was an optional feature, programmers could not rely on it for most end user applications.

Support was deprecated in Windows 8:

• https://stackoverflow.com/questions/4746043/where-does-microsoft-windows-7-posix-implementation-currently-stand
• https://superuser.com/questions/495360/does-windows-8-still-implement-posix
• Feature request: https://windows.uservoice.com/forums/265757-windows-feature-suggestions/suggestions/6573649-full-posix-support

In 2016 a new official Linux-like API called "Windows Subsystem for Linux" was announced. It includes Linux system calls, ELF running, parts of the /proc filesystem, Bash, GCC, (TODO likely glibc?), apt-get and more: https://channel9.msdn.com/Events/Build/2016/P488 so I believe that it will allow Windows to run much, if not all, of POSIX. However, it is focused on developers / deployment instead of end users. In particular, there were no plans to allow access to the Windows GUI.

Historical overview of the official Microsoft POSIX compatibility: http://brianreiter.org/2010/08/24/the-sad-history-of-the-microsoft-posix-subsystem/

Cygwin is a well known GPL third-party project for that "provides substantial POSIX API functionality" for Windows, but requires that you "rebuild your application from source if you want it to run on Windows". MSYS2 is a related project that seems to add more functionality on top of Cygwin.

If the only thing from POSIX that you need are the command line utilities, also consider: https://github.com/shelljs/shelljs which re-implements a bunch of CLI utilities in Node.js, which already essentially implements a portability layer for the simpler system calls like mkdir etc. Many people use that project in the package.json of their project to allow running the project on Windows as well. Of course, it requires users to install the Node.js runtime, but given the popularity of Node.js, I don't expect that to break/be hard to satisfy anytime soon.

Android

Android has its own C library (Bionic) which does not fully support POSIX as of Android O: https://stackoverflow.com/questions/27604455/is-android-posix-compatible

Bonus level

The Linux Standard Base further extends POSIX.

Use the non-frames indexes, they are much more readable and searchable: http://pubs.opengroup.org/onlinepubs/9699919799/nfindex.html

Get a full zipped version of the HTML pages for grepping: https://stackoverflow.com/questions/453993/is-there-a-listing-of-the-posix-api-functions/45832939#45832939

POSIX is:

> POSIX (pronounced /ˈpɒzɪks/) or > "Portable Operating System Interface > [for Unix]"1 is the name of a family > of related standards specified by the > IEEE to define the application > programming interface (API), along > with shell and utilities interfaces > for software compatible with variants > of the Unix operating system, although > the standard can apply to any > operating system.

Basically it was a set of measures to ease the pain of development and usage of different flavours of UNIX by having a (mostly) common API and utilities. Limited POSIX compliance also extended to various versions of Windows.

Let me give the churlish "unofficial" explanation.

POSIX is a set of standards which attempts to distinguish "UNIX" and UNIX-like systems from those which are incompatible with them. It was created by the U.S. government for procurement purposes. The idea was that the U.S. federal procurements needed a way to legally specify the requirements for various sorts of bids and contracts in a way that could be used to exclude systems to which a given existing code base or programming staff would NOT be portable.

Since POSIX was written post facto ... to describe a loosely similar set of competing systems ... it was NOT written in a way that could be implemented.

So, for example, Microsoft's NT was written with enough POSIX conformance to qualify for some bids ... even though the POSIX subsystem was essentially useless in terms of practical portability and compatibility with UNIX systems.

Various other standards for UNIX have been written over the decades. Things like the SPEC1170 (specified eleven hundred and seventy function calls which had to be implemented compatibly) and various incarnations of the SUS (Single UNIX Specification).

For the most part these "standards" have been inadequate to any practical technical application. They mostly exist for argumentation, legal wrangling and other dysfunctional reasons.

POSIX is a standard for operating systems that was supposed to make it easier to write cross-platform software. It's an especially big deal in the world of Unix.

POSIX is a set of standards put forth by IEEE and The Open Group that describes how an ideal Unix would operate. Programmers, users, and administrators can all become familiar with the POSIX document, and expect a POSIX-complaint Unix to provide all of the standard facilities mentioned.

Since every Unix does things a little differently -- Solaris, Mac OS X, IRIX, BSD, and Linux all have their quirks -- POSIX is especially useful to those in the industry as it defines a standard environment to operate in. For example, most of the functions in the C library are based in POSIX; a programmer can, therefore, use one in his application and expect it to behave the same across most Unices.

However, the divergent areas of Unix are typically the focus, rather than the standard ones.

The great thing about POSIX is that you're welcome to read it yourself:

> The Open Group Base Specifications Issue 7

Issue 7 is known as POSIX.1-2008, and there are new things in there -- however, Google-fu for POSIX.1 and such will allow you to see the entire history behind what Unix is.

> In 1985, individuals from companies throughout the computer industry > joined together to develop the POSIX (Portable Operating System > Interface for Computer Environments) standard, which is based largely > on the UNIX System V Interface Definition (SVID) and other earlier > standardization efforts. These efforts were spurred by the U.S. > government, which needed a standard computing environment to minimize > its training and procurement costs. Released in 1988, POSIX is a group > of IEEE standards that define the API, shell, and utility interfaces > for an operating system. Although aimed at UNIX-like systems, the > standards can apply to any compatible operating system. Now that these > stan- dards have gained acceptance, software developers are able to > develop applications that run on all conforming versions of UNIX, > Linux, and other operating systems.

From the book: A Practical Guide To Linux

Posix is more as an OS, it is an "OS standard". You can imagine it as an imaginary OS, which actually doesn't exist, but it has a documentation. These papers are the "posix standard", defined by the IEEE, which is the big standard organization of the USA. The OSes implementing this specification are "Posix-compliant".

Government regulations prefer Posix-compliant solutions in their investments, thus being Posix-compliant has a significant financial advantage, particularly for the big IT companies of the USA.

The reward for an OS being fully posix compliant, that it is a guarantee that it will compile and run all Posix-compliant applications seamlessly.

Linux is the most well-known one. OSX, Solaris, NetBSD and Windows NT play here as well. Free- and OpenBSD are only "nearly" Posix-compliant. The posix-compliance of the WinNT is only a pseudo-solution to avoid this government regulation above.

This standard provides a common basis for Unix-like operating systems. It specifies how the shell should work, what to expect from commands like ls and grep, and a number of C libraries that C authors can expect to have available.

For example, the pipes that command-line users use to string together commands are specified in detail here, which means C’s popen (pipe open) function is POSIX-standard, not ISO C-standard.

POSIX stands for Portable Operating System Interface, and is an IEEE standard designed to facilitate application portability. POSIX is an attempt by a consortium of vendors to create a single standard version of UNIX.

POSIX stands for Portable Operating System Interface.

POSIX is a set of standards codified by the IEEE and issued by ANSI and ISO. The goal of POSIX is to ease the task of cross-platform software development by establishing a set of guidelines for operating system vendors to follow. Ideally, a developer should have to write a program only once to run on all POSIX-compliant systems. Most modern commercial Unix implementations and many free ones are POSIX compliant. There are actually several different POSIX releases, but the most important are POSIX.1 and POSIX.2, which define system calls and command-line interface, respectively.

The POSIX specifications describe an operating system that is similar to, but not necessarily the same as, Unix. Though POSIX is heavily based on the BSD and System V releases, non-Unix systems such as Microsoft's Windows NT and IBM's OpenEdition MVS are POSIX compliant.

source

Posix governs interoperability, portability, and in other areas such as the usage and mechanism of fork, permissions and filesystem standards such as /etc, /var, /usr and so on . Hence, when developers write a program under a Posix compliant system such as for example Linux, it is generally, not always, guaranteed to run on another posix compliant system such as IBM's AIX system or other commercial variants of Unix. Posix is a good thing to have as such it eases the software development for maximum portability which it strives for. Hope this answer makes sense.

Thanks to Jed Smith & Tinkertim for pointing out my error - my bad!!! :(

POSIX defines set of standards for an operating system or a program. The goal is to write new software that is compatible with UNIX-like systems.

For example a program runs on Linux is also can be compile and run on other UNIX-like systems like Solaris, HP-UX, and AIX etc..

The most popular examples are GNU Bash which is 100% POSIX compliance and gawk utility.

A specification (blueprint) about how to make an OS compatible with late UNIX OS (may God bless him!). This is why macOS and GNU/Linux have very similar terminal command lines, GUI's, libraries, etc. Because they both were designed according to POSIX blueprint.

POSIX does not tell engineers and programmers how to code but what to code.

Some facts about POSIX that are not so bright.

POSIX is also the system call interface or API, and it is nearly 30 years old.

It was designed for serialized data access to local storage, using single computers with single CPUs.

Security was not a major concern in POSIX by design, leading to numerous race condition attacks over the years and forcing programmers to work around these limitations.

Serious bugs are still being discovered, bugs that could have been averted with a more secure POSIX API design.

POSIX expects users to issue one synchronous call at a time and wait for its results before issuing the next. Today's programmers expect to issue many asynchronous requests at a time to improve overall throughput.

This synchronous API is particularly bad for accessing remote and cloud objects, where high latency matters.