271 lines
13 KiB
HTML
271 lines
13 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Copyright 2001 The Open Group, All Rights Reserved -->
|
|
<title>The Base Specifications Issue 6</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
<a href="../copyr.html">Copyright</a> © 2001 The IEEE and The Open Group</font>
|
|
|
|
<hr size="2" noshade>
|
|
</center>
|
|
|
|
<p>This standard has been jointly developed by the IEEE and The Open Group. It is both an IEEE Standard and an Open Group Technical
|
|
Standard.</p>
|
|
|
|
|
|
<h5>The Austin Group</h5>
|
|
|
|
<p>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.<a href="#tag_foot_1"><sup><small>1</small></sup></a> 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 has been to revise, combine, and update the following standards: ISO/IEC 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std
|
|
1003.2, and the Base Specifications of The Open Group Single UNIX Specification.</p>
|
|
|
|
<p>After two initial meetings, an agreement was signed in July 1999 between The Open Group and the Institute of Electrical and
|
|
Electronics Engineers (IEEE), Inc., to formalize the project with the first draft of the revised specifications being made
|
|
available at the same time. Under this agreement, The Open Group and IEEE agreed to share joint copyright of the resulting work.
|
|
The Open Group has provided the chair and secretariat for the Austin Group.</p>
|
|
|
|
<p>The base document for the revision was The Open Group's Base volumes of its Single UNIX Specification, Version 2. These were
|
|
selected since they were a superset of the existing POSIX.1 and POSIX.2 specifications and had some organizational aspects that
|
|
would benefit the audience for the new revision.</p>
|
|
|
|
<p>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 and The Open Group's Technical Standard designation, and, if approved, an
|
|
ISO/IEC designation. This set of specifications forms the core of the Single UNIX Specification, Version 3.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <a href="http://www.opengroup.org/austin">http://www.opengroup.org/austin</a>.</p>
|
|
|
|
<h5>Background</h5>
|
|
|
|
<p>The developers of this standard 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.</p>
|
|
|
|
<p>Conceptually, this standard 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
|
|
writers to write portable applications-it was developed with that goal in mind-it has been designated POSIX,<a href=
|
|
"#tag_foot_2"><sup><small>2</small></sup></a> an acronym for Portable Operating System Interface.</p>
|
|
|
|
<p>Although originated to refer to the original IEEE Std 1003.1-1988, the name POSIX more correctly refers to a
|
|
<i>family</i> of related standards: IEEE Std 1003.<i>n</i> 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.</p>
|
|
|
|
<h5>Audience</h5>
|
|
|
|
<p>The intended audience for this standard is all persons concerned with an industry-wide standard operating system based on the
|
|
UNIX system. This includes at least four groups of people:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Persons buying hardware and software systems</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Persons managing companies that are deciding on future corporate computing directions</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Persons implementing operating systems, and especially</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Persons developing applications where portability is an objective</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<h5>Purpose</h5>
|
|
|
|
<p>Several principles guided the development of this standard:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>Application-Oriented</p>
|
|
|
|
<p>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. This standard codifies the common, existing definition of the UNIX system.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Interface, Not Implementation</p>
|
|
|
|
<p>This standard 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.<br>
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Source, Not Object, Portability</p>
|
|
|
|
<p>This standard 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. This standard 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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The C Language</p>
|
|
|
|
<p>The system interfaces and header definitions are written in terms of the standard C language as specified in the ISO C
|
|
standard.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>No Superuser, No System Administration</p>
|
|
|
|
<p>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 this standard. This standard is also not concerned with hardware constraints
|
|
or system maintenance.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Minimal Interface, Minimally Defined</p>
|
|
|
|
<p>In keeping with the historical design principles of the UNIX system, the mandatory core facilities of this standard have been
|
|
kept as minimal as possible. Additional capabilities have been added as optional extensions.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Broadly Implementable</p>
|
|
|
|
<p>The developers of this standard endeavored to make all specified functions implementable across a wide range of existing and
|
|
potential systems, including:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>All of the current major systems that are ultimately derived from the original UNIX system code (Version 7 or later)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Compatible systems that are not derived from the original UNIX system code</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Emulations hosted on entirely different operating systems</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Networked systems</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Distributed systems</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Systems running on a broad range of hardware</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>No direct references to this goal appear in this standard, but some results of it are mentioned in the Rationale (Informative)
|
|
volume.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Minimal Changes to Historical Implementations</p>
|
|
|
|
<p>When the original version of IEEE Std 1003.1 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.</p>
|
|
|
|
<p>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 the subsequent revisions and addenda to all of them have consolidated this consensus,
|
|
and this revision reflects the significantly increased level of consensus arrived at since the original versions. The earlier
|
|
standards and their modifications specified a number of areas where consensus had not been reached before, and these are now
|
|
reflected in this revision. The authors of the original versions tried, as much as possible, to follow the principles below when
|
|
creating new specifications:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>By standardizing an interface like one in an historical implementation; for example, directories</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>By specifying an interface that is readily implementable in terms of, and backwards-compatible with, historical implementations,
|
|
such as the extended <i>tar</i> format defined in the <a href=
|
|
"../utilities/pax.html"><i>pax</i></a> utility</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>By specifying an interface that, when added to an historical implementation, will not conflict with it; for example, the <a
|
|
href="../functions/sigaction.html"><i>sigaction</i>()</a> function</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>This revision tries to minimize the number of changes required to implementations which conform to the earlier versions of the
|
|
approved standards to bring them into conformance with the current standard. Specifically, the scope of this work excluded doing
|
|
any "new" work, but rather collecting into a single document what had been spread across a number of documents, and presenting it
|
|
in what had been proven in practice to be a more effective way. Some changes to prior conforming implementations were unavoidable,
|
|
primarily as a consequence of resolving conflicts found in prior revisions, or which became apparent when bringing the various
|
|
pieces together.</p>
|
|
|
|
<p>However, since it references the 1999 version of the ISO C standard, and no longer supports "Common Usage C", there are a
|
|
number of unavoidable changes. Applications portability is similarly affected.</p>
|
|
|
|
<p>This standard is specifically not a codification of a particular vendor's product.</p>
|
|
|
|
<p>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 this standard. These need to be
|
|
used with careful management to be able to adapt to future extensions of this standard and/or port to implementations that provide
|
|
these services in a different manner.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Minimal Changes to Existing Application Code</p>
|
|
|
|
<p>A goal of this standard was to minimize additional work for the developers of applications. However, because every known
|
|
historical implementation will have to change at least slightly to conform, some applications will have to change.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<hr>
|
|
<h4>Footnotes</h4>
|
|
|
|
<dl compact>
|
|
<dt><a name="tag_foot_1">1.</a></dt>
|
|
|
|
<dd>The Austin Group is named after the location of the inaugural meeting held at the IBM facility in Austin, Texas in September
|
|
1998.</dd>
|
|
|
|
<dt><a name="tag_foot_2">2.</a></dt>
|
|
|
|
<dd>The name POSIX was suggested by Richard Stallman. It is expected to be pronounced <i>pahz-icks</i>, as in <i>positive</i>, not
|
|
<i>poh-six</i>, or other variations. The pronunciation has been published in an attempt to promulgate a standardized way of
|
|
referring to a standard operating system interface.</dd>
|
|
</dl>
|
|
<p> </p>
|
|
|
|
<p> </p>
|
|
|
|
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
|
|
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
|
|
]</font></center>
|
|
|
|
<!--footer end-->
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|