xcu_chap01.html

posix标准英文,html格式

<p>The second command is equivalent to the first only when the file is seekable. In the third command, if the file offset in the
open file description were not unspecified, <a href="../utilities/sed.html"><i>sed</i></a> would have to be implemented so that it
read from the pipe 1 byte at a time or it would have to employ some method to seek backwards on the pipe. Such functionality is not
defined currently in POSIX.1 and does not exist on all historical systems. Other utilities, such as <a href=
"../utilities/head.html"><i>head</i></a>, <a href="../utilities/read.html"><i>read</i></a>, and <a href=
"../utilities/sh.html"><i>sh</i></a>, have similar properties, so the restriction is described globally in this section.</p>

<p>The definition of &quot;text file&quot; is strictly enforced for input to the standard utilities; very few of them list exceptions to
the undefined results called for here. (Of course, &quot;undefined&quot; here does not mean that historical implementations necessarily
have to change to start indicating error conditions. Conforming applications cannot rely on implementations succeeding or failing
when non-text files are used.)</p>

<p>The utilities that allow line continuation are generally those that accept input languages, rather than pure data. It would be
unusual for an input line of this type to exceed {LINE_MAX} bytes and unreasonable to require that the implementation allow
unlimited accumulation of multiple lines, each of which could reach {LINE_MAX}. Thus, for a conforming application the total of all
the continued lines in a set cannot exceed {LINE_MAX}.</p>

<p>The format description is intended to be sufficiently rigorous to allow other applications to generate these input files.
However, since &lt;blank&gt;s can legitimately be included in some of the fields described by the standard utilities, particularly
in locales other than the POSIX locale, this intent is not always realized.</p>

<h5><a name="tag_02_01_11_08"></a>ENVIRONMENT VARIABLES</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_01_11_09"></a>ASYNCHRONOUS EVENTS</h5>

<p>Because there is no language prohibiting it, a utility is permitted to catch a signal, perform some additional processing (such
as deleting temporary files), restore the default signal action (or action inherited from the parent process), and resignal
itself.</p>

<h5><a name="tag_02_01_11_10"></a>STDOUT</h5>

<p>The format description is intended to be sufficiently rigorous to allow post-processing of output by other programs,
particularly by an <a href="../utilities/awk.html"><i>awk</i></a> or <a href="../utilities/lex.html"><i>lex</i></a> parser.</p>

<h5><a name="tag_02_01_11_11"></a>STDERR</h5>

<p>This section does not describe error messages that refer to incorrect operation of the utility. Consider a utility that
processes program source code as its input. This section is used to describe messages produced by a correctly operating utility
that encounters an error in the program source code on which it is processing. However, a message indicating that the utility had
insufficient memory in which to operate would not be described.</p>

<p>Some utilities have traditionally produced warning messages without returning a non-zero exit status; these are specifically
noted in their sections. Other utilities shall not write to standard error if they complete successfully, unless the implementation
provides some sort of extension to increase the verbosity or debugging level.</p>

<p>The format descriptions are intended to be sufficiently rigorous to allow post-processing of output by other programs.</p>

<h5><a name="tag_02_01_11_12"></a>OUTPUT FILES</h5>

<p>The format description is intended to be sufficiently rigorous to allow post-processing of output by other programs,
particularly by an <a href="../utilities/awk.html"><i>awk</i></a> or <a href="../utilities/lex.html"><i>lex</i></a> parser.</p>

<p>Receipt of the SIGQUIT signal should generally cause termination (unless in some debugging mode) that would bypass any attempted
recovery actions.</p>

<h5><a name="tag_02_01_11_13"></a>EXTENDED DESCRIPTION</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_01_11_14"></a>EXIT STATUS</h5>

<p>Note the additional discussion of exit values in <i>Exit Status for Commands</i> in the <a href=
"../utilities/sh.html"><i>sh</i></a> utility. It describes requirements for returning exit values greater than 125.</p>

<p>A utility may list zero as a successful return, 1 as a failure for a specific reason, and greater than 1 as &quot;an error
occurred&quot;. In this case, unspecified conditions may cause a 2 or 3, or other value, to be returned. A strictly conforming
application should be written so that it tests for successful exit status values (zero in this case), rather than relying upon the
single specific error value listed in IEEE&nbsp;Std&nbsp;1003.1-2001. In that way, it will have maximum portability, even on
implementations with extensions.</p>

<p>The standard developers are aware that the general non-enumeration of errors makes it difficult to write test suites that test
the <i>incorrect</i> operation of utilities. There are some historical implementations that have expended effort to provide
detailed status messages and a helpful environment to bypass or explain errors, such as prompting, retrying, or ignoring
unimportant syntax errors; other implementations have not. Since there is no realistic way to mandate system behavior in cases of
undefined application actions or system problems-in a manner acceptable to all cultures and environments-attention has been limited
to the correct operation of utilities by the conforming application. Furthermore, the conforming application does not need detailed
information concerning errors that it caused through incorrect usage or that it cannot correct.</p>

<p>There is no description of defaults for this section because all of the standard utilities specify something (or explicitly
state &quot;Unspecified&quot;) for exit status.</p>

<h5><a name="tag_02_01_11_15"></a>CONSEQUENCES OF ERRORS</h5>

<p>Several actions are possible when a utility encounters an error condition, depending on the severity of the error and the state
of the utility. Included in the possible actions of various utilities are: deletion of temporary or intermediate work files;
deletion of incomplete files; and validity checking of the file system or directory.</p>

<p>The text about recursive traversing is meant to ensure that utilities such as <a href="../utilities/find.html"><i>find</i></a>
process as many files in the hierarchy as they can. They should not abandon all of the hierarchy at the first error and resume with
the next command-line operand, but should attempt to keep going.</p>

<h5><a name="tag_02_01_11_16"></a>APPLICATION USAGE</h5>

<p>This section provides additional caveats, issues, and recommendations to the developer.</p>

<h5><a name="tag_02_01_11_17"></a>EXAMPLES</h5>

<p>This section provides sample usage.</p>

<h5><a name="tag_02_01_11_18"></a>RATIONALE</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_01_11_19"></a>FUTURE DIRECTIONS</h5>

<p>FUTURE DIRECTIONS sections act as pointers to related work that may impact the interface in the future, and often cautions the
developer to architect the code to account for a change in this area. Note that a future directions statement should not be taken
as a commitment to adopt a feature or interface in the future.</p>

<h5><a name="tag_02_01_11_20"></a>SEE ALSO</h5>

<p>There is no additional rationale provided for this section.</p>

<h5><a name="tag_02_01_11_21"></a>CHANGE HISTORY</h5>

<p>There is no additional rationale provided for this section.</p>

<h4><a name="tag_02_01_12">  C.1.12 </a>Considerations for Utilities in Support of Files of Arbitrary Size</h4>

<p>This section is intended to clarify the requirements for utilities in support of large files.</p>

<p>The utilities listed in this section are utilities which are used to perform administrative tasks such as to create, move, copy,
remove, change the permissions, or measure the resources of a file. They are useful both as end-user tools and as utilities invoked
by applications during software installation and operation.</p>

<p>The <a href="../utilities/chgrp.html"><i>chgrp</i></a>, <a href="../utilities/chmod.html"><i>chmod</i></a>, <a href=
"../utilities/chown.html"><i>chown</i></a>, <a href="../utilities/ln.html"><i>ln</i></a>, and <a href=
"../utilities/rm.html"><i>rm</i></a> utilities probably require use of large file-capable versions of <a href=
"../functions/stat.html"><i>stat</i>()</a>, <a href="../functions/lstat.html"><i>lstat</i>()</a>, <a href=
"../functions/ftw.html"><i>ftw</i>()</a>, and the <b>stat</b> structure.</p>

<p>The <a href="../utilities/cat.html"><i>cat</i></a>, <a href="../utilities/cksum.html"><i>cksum</i></a>, <a href=
"../utilities/cmp.html"><i>cmp</i></a>, <a href="../utilities/cp.html"><i>cp</i></a>, <a href="../utilities/dd.html"><i>dd</i></a>,
<a href="../utilities/mv.html"><i>mv</i></a>, <i>sum</i>, and <a href="../utilities/touch.html"><i>touch</i></a> utilities probably
require use of large file-capable versions of <a href="../functions/creat.html"><i>creat</i>()</a>, <a href=
"../functions/open.html"><i>open</i>()</a>, and <a href="../functions/fopen.html"><i>fopen</i>()</a>.</p>

<p>The <a href="../utilities/cat.html"><i>cat</i></a>, <a href="../utilities/cksum.html"><i>cksum</i></a>, <a href=
"../utilities/cmp.html"><i>cmp</i></a>, <a href="../utilities/dd.html"><i>dd</i></a>, <a href="../utilities/df.html"><i>df</i></a>,
<a href="../utilities/du.html"><i>du</i></a>, <a href="../utilities/ls.html"><i>ls</i></a>, and <i>sum</i> utilities may require
writing large integer values. For example:</p>

<ul>
<li>
<p>The <a href="../utilities/cat.html"><i>cat</i></a> utility might have a <b>-n</b> option which counts &lt;newline&gt;s.</p>
</li>

<li>
<p>The <a href="../utilities/cksum.html"><i>cksum</i></a> and <a href="../utilities/ls.html"><i>ls</i></a> utilities report file
sizes.</p>
</li>

<li>
<p>The <a href="../utilities/cmp.html"><i>cmp</i></a> utility reports the line number at which the first difference occurs, and
also has a <b>-l</b> option which reports file offsets.</p>
</li>

<li>
<p>The <a href="../utilities/dd.html"><i>dd</i></a>, <a href="../utilities/df.html"><i>df</i></a>, <a href=
"../utilities/du.html"><i>du</i></a>, <a href="../utilities/ls.html"><i>ls</i></a>, and <i>sum</i> utilities report block
counts.</p>
</li>
</ul>

<p>The <a href="../utilities/dd.html"><i>dd</i></a>, <a href="../utilities/find.html"><i>find</i></a>, and <a href=
"../utilities/test.html"><i>test</i></a> utilities may need to interpret command arguments that contain 64-bit values. For <a href=
"../utilities/dd.html"><i>dd</i></a>, the arguments include <i>skip</i>= <i>n</i>, <i>seek</i>= <i>n</i>, and <i>count</i>=
<i>n</i>. For <a href="../utilities/find.html"><i>find</i></a>, the arguments include <b>-size</b> <i>n</i>. For <a href=
"../utilities/test.html"><i>test</i></a>, the arguments are those associated with algebraic comparisons.</p>

<p>The <a href="../utilities/df.html"><i>df</i></a> utility might need to access large file systems with <a href=
"../functions/statvfs.html"><i>statvfs</i>()</a>.</p>

<p>The <a href="../utilities/ulimit.html"><i>ulimit</i></a> utility will need to use large file-capable versions of <a href=
"../functions/getrlimit.html"><i>getrlimit</i>()</a> and <a href="../functions/setrlimit.html"><i>setrlimit</i>()</a> and be able
to read and write large integer values.</p>

<h4><a name="tag_02_01_13">  C.1.13 </a>Built-In Utilities</h4>

<p>All of these utilities can be <i>exec</i>-ed. There is no requirement that these utilities are actually built into the shell
itself, but many shells need the capability to do so because the Shell and Utilities volume of IEEE&nbsp;Std&nbsp;1003.1-2001, <a
href="../utilities/xcu_chap02.html#tag_02_09_01_01">Section 2.9.1.1, Command Search and Execution</a> requires that they be found
prior to the <i>PATH</i> search. The shell could satisfy its requirements by keeping a list of the names and directly accessing the
file-system versions regardless of <i>PATH .</i> Providing all of the required functionality for those such as <a href=
"../utilities/cd.html"><i>cd</i></a> or <a href="../utilities/read.html"><i>read</i></a> would be more difficult.</p>

<p>There were originally three justifications for allowing the omission of <i>exec</i>-able versions:</p>

<ol>
<li>
<p>It would require wasting space in the file system, at the expense of very small systems. However, it has been pointed out that
all 16 utilities in the table can be provided with 16 links to a single-line shell script:</p>

<pre>
<tt>$0 "$@"
</tt>
</pre>
</li>

<li>
<p>It is not logical to require invocation of utilities such as <a href="../utilities/cd.html"><i>cd</i></a> because they have no
value outside the shell environment or cannot be useful in a child process. However, counter-examples always seemed to be available
for even the most unusual cases:</p>

<pre>
<tt>find . -type d -exec cd {} \; -exec foo {} \;
   </tt> (which invokes &quot;foo&quot; on accessible directories)<tt><br>
ps ... | sed ... | xargs kill
<br>
find . -exec true \; -a ...
   </tt> (where &quot;true&quot; is used for temporary debugging)
</pre>
</li>

<li>
<p>It is confusing to have a utility such as <a href="../utilities/kill.html"><i>kill</i></a> that can easily be in the file system
in the base standard, but that requires built-in status for the User Portability Utilities option (for the <tt>%</tt> job control
job ID notation). It was decided that it was more appropriate to describe the required functionality (rather than the
implementation) to the system implementors and let them decide how to satisfy it.</p>
</li>
</ol>

<p>On the other hand, it was realized that any distinction like this between utilities was not useful to applications, and that the
cost to correct it was small. These arguments were ultimately the most effective.</p>

<p>There were varying reasons for including utilities in the table of built-ins:</p>

<dl compact>
<dt><i>alias</i>, <i>fc</i>, <i>unalias</i></dt>

<dd>
The functionality of these utilities is performed more simply within the shell itself and that is the model most historical
implementations have used.</dd>

<dt><i>bg</i>, <i>fg</i>, <i>jobs</i></dt>

<dd>
All of the job control-related utilities are eligible for built-in status because that is the model most historical implementations
have used.</dd>

<dt><i>cd</i>, <i>getopts</i>, <i>newgrp</i>, <i>read</i>, <i>umask</i>, <i>wait</i></dt>

<dd>
 The functionality of these utilities is performed more simply within the context of the current process. An example can be taken
from the usage of the <a href="../utilities/cd.html"><i>cd</i></a> utility. The purpose of the <a href=
"../utilities/cd.html"><i>cd</i></a> utility is to change the working directory for subsequent operations. The actions of <a href=
"../utilities/cd.html"><i>cd</i></a> affect the process in which <a href="../utilities/cd.html"><i>cd</i></a> is executed and all
subsequent child processes of that process. Based on the POSIX standard process model, changes in the process environment of a
child process have no effect on the parent process. If the <a href="../utilities/cd.html"><i>cd</i></a> utility were executed from
a child process, the working directory change would be effective only in the child process. Child processes initiated subsequent to
the child process that executed the <a href="../utilities/cd.html"><i>cd</i></a> utility would not have a changed working directory
relative to the parent process.</dd>

<dt><i>command</i></dt>

<dd>
This utility was placed in the table primarily to protect scripts that are concerned about their <i>PATH</i> being manipulated. The
&quot;secure&quot; shell script example in the <a href="../utilities/command.html"><i>command</i></a> utility in the Shell and Utilities
volume of IEEE&nbsp;Std&nbsp;1003.1-2001 would not be possible if a <i>PATH</i> change retrieved an alien version of <a href=
"../utilities/command.html"><i>command</i></a>. (An alternative would have been to implement <a href=
"../utilities/getconf.html"><i>getconf</i></a> as a built-in, but the standard developers considered that it carried too many
changing configuration strings to require in the shell.)</dd>

<dt><i>kill</i></dt>

<dd>Since <a href="../utilities/kill.html"><i>kill</i></a> provides optional job control functionality using shell notation (
<tt>%1</tt>, <tt>%2</tt>, and so on), some implementations would find it extremely difficult to provide this outside the
shell.</dd>

<dt><i>true</i>, <i>false</i></dt>

<dd>
These are in the table as a courtesy to programmers who wish to use the <tt>"while&nbsp;true"</tt> shell construct without
protecting <a href="../utilities/true.html"><i>true</i></a> from <i>PATH</i> searches. (It is acknowledged that
<tt>"while&nbsp;:"</tt> also works, but the idiom with <a href="../utilities/true.html"><i>true</i></a> is historically
pervasive.)</dd>
</dl>

<p>All utilities, including those in the table, are accessible via the <a href="../functions/system.html"><i>system</i>()</a> and
<a href="../functions/popen.html"><i>popen</i>()</a> functions in the System Interfaces volume of IEEE&nbsp;Std&nbsp;1003.1-2001.
There are situations where the return functionality of <a href="../functions/system.html"><i>system</i>()</a> and <a href=
"../functions/popen.html"><i>popen</i>()</a> is not desirable. Applications that require the exit status of the invoked utility
will not be able to use <a href="../functions/system.html"><i>system</i>()</a> or <a href=
"../functions/popen.html"><i>popen</i>()</a>, since the exit status returned is that of the command language interpreter rather
than that of the invoked utility. The alternative for such applications is the use of the <i>exec</i> family.</p>


<hr size="2" noshade>
<center><font size="2"><!--footer start-->
UNIX &reg; is a registered Trademark of The Open Group.<br>
POSIX &reg; 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>