Sorting out what the Single Unix Specification is and covers

October 8, 2020

I've linked to the Single Unix Specification any number of times, for various versions of it (when I first linked to it, it was at issue 6, in 2006; it's now up to a 2018 edition). But I've never been quite clear what it covered and didn't cover, and how it related to POSIX and similar things. After yesterday's entry got me looking at the SuS site again, I decided to try to sort this out once and for all.

My primary resources on this is the Wikipedia page (the SuS FAQ claims to be updated recently but is clearly out of date in important respects). Also useful is the page of the Austin Commons Standards Revision Group (also). The Wikipedia page has a helpful rundown of the history of the 'Single Unix Specification' and some things related to them.

As stated by various places, the core of the Single Unix Specification is POSIX, which is formally an IEEE standard and also an international ISO/IEC standard (IEEE 1003 and ISO/IEC 9945 respectively). POSIX incorporates by reference some vintage of ANSI C (I believe C99), since the Unix APIs it specifies are specified in C. The POSIX standard covers both C library APIs, commands that are executed through the shell (which is also specified in POSIX), and I believe things like some file paths. As far as I can tell, the only other standard in the Single Unix Specification is CURSES, which is not part of POSIX.

(See eg here Unix standards, the FAQ, and Wikipedia.)

This implies that if a Unix command or a non-Curses API is in the Single Unix Specification, it's also in POSIX. This matches what I've seen in the online Single Unix Specification that I keep linking to bits of; I've only ever noticed it talking about POSIX (aka IEEE 1003.1). For most purposes, then, I can just talk about 'POSIX' or 'Single Unix Specification' interchangeably, which is somewhat different than how I used to think it was.

(I originally thought that the SuS was a superset of POSIX that added significant extra commands and requirements that were not in POSIX. This appears to not be the case.)

Sidebar: Where my misunderstanding of SuS came from

How I thought the story went was that POSIX was a relatively minimal standard for 'Unix' that did not go far enough in practice, for various political reasons. This caused actual Unix vendors to get together and agree on an additional layer of things on top of POSIX that made up 'Unix in practice', creating the Single Unix Specification. Systems that were in no way Unix derived could be POSIX compliant if they tried (and so could be candidates for US government contracts that required 'POSIX', per the origins of POSIX as I learned them), but could not be Unix™, which was something that was defined by the Single Unix Specification.

Obviously this is not actually the case, or at least is not the case in modern versions of the SuS. This goes to show me, once again, the power of folklore (especially since I fell for it).

Written on 08 October 2020.
« A handy diff argument handling feature that's actually very old
Whether extra disks should be live or spare now depends on HDs versus SSDs »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Oct 8 00:38:03 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.