📄 xbd_chap03.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta name="generator" content="HTML Tidy, see www.w3.org"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 --><!-- Copyright (c) 2001-2003 The Open Group, All Rights Reserved --><title>Rationale</title></head><body><basefont size="3"> <center><font size="2">The Open Group Base Specifications Issue 6<br>IEEE Std 1003.1, 2003 Edition<br>Copyright © 2001-2003 The IEEE and The Open Group</font></center><hr size="2" noshade><h3><a name="tag_01_03"></a>Definitions</h3><p>The definitions in this section are stated so that they can be used as exact substitutes for the terms in text. They should notcontain requirements or cross-references to sections within IEEE Std 1003.1-2001; that is accomplished by using aninformative note. In addition, the term should not be included in its own definition. Where requirements or descriptions need to beaddressed but cannot be included in the definitions, due to not meeting the above criteria, these occur in the General Conceptschapter.</p><p>In this revision, the definitions have been reworked extensively to meet style requirements and to include terms from the basedocuments (see the Scope).</p><p>Many of these definitions are necessarily circular, and some of the terms (such as "process") are variants of basic computingscience terms that are inherently hard to define. Where some definitions are more conceptual and contain requirements, these appearin the General Concepts chapter. Those listed in this section appear in an alphabetical glossary format of terms.</p><p>Some definitions must allow extension to cover terms or facilities that are not explicitly mentioned inIEEE Std 1003.1-2001. For example, the definition of "Extended Security Controls" permits implementations beyond thosedefined in IEEE Std 1003.1-2001.</p><p>Some terms in the following list of notes do not appear in IEEE Std 1003.1-2001; these are marked suffixed with anasterisk (*). Many of them have been specifically excluded from IEEE Std 1003.1-2001 because they concern systemadministration, implementation, or other issues that are not specific to the programming interface. Those are marked with a reason,such as "implementation-defined".</p><h5><a name="tag_01_03_00_01"></a>Appropriate Privileges</h5><p>One of the fundamental security problems with many historical UNIX systems has been that the privilege mechanism is monolithic-auser has either no privileges or <i>all</i> privileges. Thus, a successful "trojan horse" attack on a privileged process defeatsall security provisions. Therefore, POSIX.1 allows more granular privilege mechanisms to be defined. For many historicalimplementations of the UNIX system, the presence of the term "appropriate privileges" in POSIX.1 may be understood as a synonymfor "superuser" (UID 0). However, other systems have emerged where this is not the case and each discrete controllable action has<i>appropriate privileges</i> associated with it. Because this mechanism is implementation-defined, it must be described in theconformance document. Although that description affects several parts of POSIX.1 where the term "appropriate privilege" is used,because the term "implementation-defined" only appears here, the description of the entire mechanism and its effects on theseother sections belongs in this equivalent section of the conformance document. This is especially convenient for implementationswith a single mechanism that applies in all areas, since it only needs to be described once.</p><h5><a name="tag_01_03_00_02"></a>Byte</h5><p>The restriction that a byte is now exactly eight bits was a conscious decision by the standard developers. It came about due toa combination of factors, primarily the use of the type <b>int8_t</b> within the networking functions and the alignment with theISO/IEC 9899:1999 standard, where the <b>intN_t</b> types are now defined.</p><p>According to the ISO/IEC 9899:1999 standard:</p><ul><li><p>The <b>[u]intN_t</b> types must be two's complement with no padding bits and no illegal values.</p></li><li><p>All types (apart from bit fields, which are not relevant here) must occupy an integral number of bytes.</p></li><li><p>If a type with width <i>W</i> occupies <i>B</i> bytes with <i>C</i> bits per byte ( <i>C</i> is the value of {CHAR_BIT}), thenit has <i>P</i> padding bits where <i>P</i>+ <i>W</i>= <i>B</i>* <i>C</i>.</p></li><li><p>Therefore, for <b>int8_t</b> <i>P</i>=0, <i>W</i>=8. Since <i>B</i>>=1, <i>C</i>>=8, the only solution is <i>B</i>=1,<i>C</i>=8.</p></li></ul><p>The standard developers also felt that this was not an undue restriction for the current state-of-the-art for this version ofIEEE Std 1003.1, but recognize that if industry trends continue, a wider character type may be required in thefuture.</p><h5><a name="tag_01_03_00_03"></a>Character</h5><p>The term "character" is used to mean a sequence of one or more bytes representing a single graphic symbol. The deviation inthe exact text of the ISO C standard definition for "byte" meets the intent of the rationale of the ISO C standard alsoclears up the ambiguity raised by the term "basic execution character set". The octet-minimum requirement is a reflection of the{CHAR_BIT} value.</p><h5><a name="tag_01_03_00_04"></a>Clock Tick</h5><p>The ISO C standard defines a similar interval for use by the <a href="../functions/clock.html"><i>clock</i>()</a> function.There is no requirement that these intervals be the same. In historical implementations these intervals are different.</p><h5><a name="tag_01_03_00_05"></a>Command</h5><p>The terms "command" and "utility" are related but have distinct meanings. Command is defined as "a directive to a shell toperform a specific task". The directive can be in the form of a single utility name (for example, <a href="../utilities/ls.html"><i>ls</i></a>), or the directive can take the form of a compound command (for example, <tt>"ls | grep name |pr"</tt> ). A utility is a program that can be called by name from a shell. Issuing only the name of the utility to a shell is theequivalent of a one-word command. A utility may be invoked as a separate program that executes in a different process than thecommand language interpreter, or it may be implemented as a part of the command language interpreter. For example, the <a href="../utilities/echo.html"><i>echo</i></a> command (the directive to perform a specific task) may be implemented such that the <ahref="../utilities/echo.html"><i>echo</i></a> utility (the logic that performs the task of echoing) is in a separate program;therefore, it is executed in a process that is different from the command language interpreter. Conversely, the logic that performsthe <a href="../utilities/echo.html"><i>echo</i></a> utility could be built into the command language interpreter; therefore, itcould execute in the same process as the command language interpreter.</p><p>The terms "tool" and "application" can be thought of as being synonymous with "utility" from the perspective of theoperating system kernel. Tools, applications, and utilities historically have run, typically, in processes above the kernel level.Tools and utilities historically have been a part of the operating system non-kernel code and have performed system-relatedfunctions, such as listing directory contents, checking file systems, repairing file systems, or extracting system statusinformation. Applications have not generally been a part of the operating system, and they perform non-system-related functions,such as word processing, architectural design, mechanical design, workstation publishing, or financial analysis. Utilities havemost frequently been provided by the operating system distributor, applications by third-party software distributors, or by theusers themselves. Nevertheless, IEEE Std 1003.1-2001 does not differentiate between tools, utilities, and applicationswhen it comes to receiving services from the system, a shell, or the standard utilities. (For example, the <a href="../utilities/xargs.html"><i>xargs</i></a> utility invokes another utility; it would be of fairly limited usefulness if the userscould not run their own applications in place of the standard utilities.) Utilities are not applications in the sense that they arenot themselves subject to the restrictions of IEEE Std 1003.1-2001 or any other standard-there is no requirement for <ahref="../utilities/grep.html"><i>grep</i></a>, <a href="../utilities/stty.html"><i>stty</i></a>, or any of the utilities definedhere to be any of the classes of conforming applications.</p><h5><a name="tag_01_03_00_06"></a>Column Positions</h5><p>In most 1-byte character sets, such as ASCII, the concept of column positions is identical to character positions and to bytes.Therefore, it has been historically acceptable for some implementations to describe line folding or tab stops or table columnalignment in terms of bytes or character positions. Other character sets pose complications, as they can have internalrepresentations longer than one octet and they can have display characters that have different widths on the terminal screen orprinter.</p><p>In IEEE Std 1003.1-2001 the term "column positions" has been defined to mean character-not byte-positions in inputfiles (such as "column position 7 of the FORTRAN input"). Output files describe the column position in terms of the display widthof the narrowest printable character in the character set, adjusted to fit the characteristics of the output device. It is verypossible that <i>n</i> column positions will not be able to hold <i>n</i> characters in some character sets, unless all of thosecharacters are of the narrowest width. It is assumed that the implementation is aware of the width of the various characters,deriving this information from the value of <i>LC_CTYPE ,</i> and thus can determine how many column positions to allot for eachcharacter in those utilities where it is important.</p><p>The term "column position" was used instead of the more natural "column" because the latter is frequently used in thedifferent contexts of columns of figures, columns of table values, and so on. Wherever confusion might result, these latter typesof columns are referred to as "text columns".</p><h5><a name="tag_01_03_00_07"></a>Controlling Terminal</h5><p>The question of which of possibly several special files referring to the terminal is meant is not addressed in POSIX.1. Thefilename <b>/dev/tty</b> is a synonym for the controlling terminal associated with a process.</p><h5><a name="tag_01_03_00_08"></a>Device Number*</h5><p>The concept is handled in <a href="../functions/stat.html"><i>stat</i>()</a> as <i>ID of device</i>.</p><h5><a name="tag_01_03_00_09"></a>Direct I/O</h5><p>Historically, direct I/O refers to the system bypassing intermediate buffering, but may be extended to coverimplementation-defined optimizations.</p><h5><a name="tag_01_03_00_10"></a>Directory</h5><p>The format of the directory file is implementation-defined and differs radically between System V and 4.3 BSD. However,routines (derived from 4.3 BSD) for accessing directories and certain constraints on the format of the information returned bythose routines are described in the <a href="../basedefs/dirent.h.html"><i><dirent.h></i></a> header.</p><h5><a name="tag_01_03_00_11"></a>Directory Entry</h5><p>Throughout IEEE Std 1003.1-2001, the term "link" is used (about the <a href="../functions/link.html"><i>link</i>()</a> function, for example) in describing the objects that point to files fromdirectories.</p><h5><a name="tag_01_03_00_12"></a>Display</h5><p>The Shell and Utilities volume of IEEE Std 1003.1-2001 assigns precise requirements for the terms "display" and"write". Some historical systems have chosen to implement certain utilities without using the traditional file descriptor model.For example, the <a href="../utilities/vi.html"><i>vi</i></a> editor might employ direct screen memory updates on a personal⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -