utildes.html

unix 下的C开发手册,还用详细的例程。

(or action inherited from the parent process) and resignal itself.

<dt><B>STDOUT</B><dd>
The STDOUT section describes the standard output
of the utility.
This section is frequently merely a reference to
the following section, OUTPUT FILES,
because many utilities treat standard output
and output files in the same manner.

Use of a terminal for standard output may cause
any of the standard utilities that write standard output
to stop when used in the background.
For this reason, applications should not use interactive features in
scripts to be placed in the background.

Record formats are described in a notation
similar to that used by the C-language function,
<i><a href="../xsh/printf.html">printf()</a></i>.
See the <B>XBD</B> specification, <a href="../xbd/notation.html"><B>File Format Notation</B>&nbsp;</a>  for a description of this notation.

The specified standard output of the standard utilities
does not depend on the existence or value of the
environment variables defined in this specification, except
as provided by this specification.

Some of the standard utilities
describe their output using the verb
<I>display</I>,
defined in the <B>XBD</B> specification, <a href="../xbd/glossary.html"><B>Glossary</B>&nbsp;</a> .
Output described in the STDOUT sections
of such utilities may be produced using means other than standard output.
When standard output is directed to a terminal,
the output described will be written directly
to the terminal.
Otherwise, the results are undefined.

<B>Default Behaviour:</B>
When this section is listed as &quot;Not used&quot;,
it means that the standard output will not be written
when the utility is used as described by this specification.

<dt><B>STDERR</B><dd>
The STDERR section describes the standard error output
of the utility.
Only those messages that are purposely sent by the
utility are described.

Use of a terminal for standard error may cause
any of the standard utilities that write standard error output
to stop when used in the background.
For this reason, applications should not use interactive features in
scripts to be placed in the background.

The format of diagnostic messages for most utilities
is unspecified, but the language and cultural conventions
of diagnostic and informative messages whose format is
unspecified by this standard should be affected by
the setting of
<i>LC_MESSAGES</i>
and
<i>NLSPATH .
</i>
The specified standard error output of standard utilities
does not depend on the existence or value of
the environment variables defined in this specification, except
as provided by this specification.

<B>Default Behaviour:</B>
When this section is listed as &quot;Used only for diagnostic messages,&quot;
it means that, unless otherwise stated,
the diagnostic messages are sent
to the standard error only when the exit status is non-zero
and the utility is used as described by this specification.

When this section is listed as &quot;Not used&quot;,
it means that the standard error will not be used
when the utility is used as described in this specification.

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.

Some compilers have traditionally produced warning messages
without returning a non-zero exit status;
these are specifically noted in their sections.
Other utilities are expected to remain absolutely quiet on
the standard error if they want to return zero,
unless the implementation provides some sort of extension
to increase the verbosity or debugging level.

<dt><B>OUTPUT FILES</B><dd>
The OUTPUT FILES section describes the files created or modified
by the utility.
Temporary or system files that are created for internal usage
by this utility or other parts of the implementation
(for example, spool, log and audit files)
are not described in this, or any, section.
The utilities creating such files
and the names of such files are unspecified.
If applications are written to use temporary or intermediate
files, they should use the
<i>TMPDIR</i>
environment variable, if it is set and
represents an accessible directory,
to select the location of temporary files.

Temporary files used by the standard utilities
are named so that different utilities or multiple
instances of the same utility can operate
simultaneously without regard to their working
directories, or any other process characteristic other
than process ID.
There are two exceptions to this rule:
<ol>

<li>
Resources for temporary files other than
the name space (for example, disk space,
available directory entries, or number of
processes allowed) are not guaranteed.

<li>
Certain standard utilities generate output files
that are intended as input for other utilities,
(for example,
<i><a href="lex.html">lex</a></i>
generates
<b>lex.yy.c )</b>
and these cannot have unique names.
These cases are explicitly identified in the
descriptions of the respective utilities.

</ol>

Any temporary file created by the implementation is removed
by the implementation upon a utility's successful exit,
exit because of errors, or before termination by any of the
SIGHUP, SIGINT or SIGTERM signals,
unless specified otherwise by the utility description.

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

Record formats are described in a notation
similar to that used by the C-language function,
<i><a href="../xsh/printf.html">printf()</a></i>.
See the <B>XBD</B> specification, <a href="../xbd/notation.html"><B>File Format Notation</B>&nbsp;</a>  for a description of this notation.

<B>Default Behaviour:</B>
When this section is listed as &quot;None&quot;,
it means
that no files are created or modified as a consequence of direct
action on the part of the utility when the utility is used as described
by this specification.
However, the utility may create or modify system files,
such as log files, that are outside the utility's normal
execution environment.

<dt><B>EXTENDED DESCRIPTION</B><dd>
The EXTENDED DESCRIPTION
section provides a place for describing the actions of very
complicated utilities, such as text editors or language processors,
which typically have elaborate command languages.

<B>Default Behaviour:</B>
When this section is listed as &quot;None&quot;,
no further description is necessary.

<dt><B>EXIT STATUS</B><dd>
The EXIT STATUS
section describes the values the utility will return to the
calling program, or shell,
and the conditions that cause these values to be returned.
Usually, utilities return zero for successful completion
and values greater than zero for various error conditions.
If specific numeric values are listed in this section,
the system will use those values for the
errors described.
In some cases, status values are listed more loosely,
such as &quot;&gt;0&quot;.
A portable application
cannot rely on any specific value in the range
shown and must be prepared to receive any value in the range.

For example, a utility may list zero as a successful return,
1 as a failure for a specific reason, and &gt;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 portable 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 this specification.
In that way, it will have maximum portability, even on
implementations with extensions.

Unspecified error conditions may be represented
by specific values not listed in this specification.

<dt><B>CONSEQUENCES OF ERRORS</B><dd>
The CONSEQUENCES OF ERRORS
section describes the effects on the environment, file systems,
process state, and so on, when error conditions occur.
It does not describe error messages produced
or exit status values used.

The many reasons for failure of a utility
are generally not specified by the utility descriptions.
Utilities may terminate prematurely if they encounter:
invalid usage of options, arguments or environment
variables; invalid usage of the complex syntaxes expressed in
EXTENDED DESCRIPTION sections; difficulties accessing,
creating, reading or writing files; or
difficulties associated with the privileges of the process.

The following apply to each utility, unless otherwise stated:
<ul>

<li>
If the requested action cannot be performed
on an operand representing a file, directory, user, process,
and so on, the utility will issue
a diagnostic message to standard error and continue processing the
next operand in sequence, but the final exit status is
returned as non-zero.

For a utility that recursively traverses a file hierarchy (such as
<i><a href="find.html">find</a></i>
or
<i><a href="chown.html">chown</a></i>
<b>-R</b>),
if the requested action cannot be performed on a file or directory
encountered in the hierarchy, the utility will issue a diagnostic message to
standard error and continue processing the remaining files in the hierarchy,
but the final exit status will be returned as non-zero.


<li>
If the requested action characterised by an option or option-argument
cannot be performed, the utility will issue a diagnostic message to
standard error and the exit status returned will be non-zero.


<li>
When an unrecoverable error condition
is encountered, the utility will exit with a non-zero exit status.

<li>
A diagnostic message will be written to standard error whenever an error
condition occurs.

</ul>

When a utility encounters an error condition several actions are
possible, 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; validity checking of the file system or directory.

<B>Default Behaviour:</B>
When this section is listed as &quot;Default&quot;,
it means that
any changes to the environment are unspecified.

<dt><B>APPLICATION USAGE</B><dd>
The APPLICATION USAGE section gives advice to the application programmer
or user about the way the utility should be used.

<dt><B>EXAMPLES</B><dd>
The EXAMPLES section gives one or more examples of usage, where appropriate.
This section is non-normative.  In the event of conflict between an 
example and a normative part of the specification, the normative 
material is to be taken as correct.

In all examples, quoting has been used, showing how sample
commands (utility names combined with arguments) could be passed
correctly to a shell
(see
<i><a href="sh.html">sh</a></i>)
or as a string to the <B>XSH</B> specification
<i><a href="../xsh/system.html">system()</a></i>
function.
Such quoting would not be used if the utility is invoked
using one of the <B>XSH</B> specification
<I>exec</I>
functions.

<dt><B>FUTURE DIRECTIONS</B><dd>
The FUTURE DIRECTIONS section
should be used as a guide to current thinking;
there is not necessarily a commitment to implement
all of these future directions in their entirety.

<dt><B>SEE ALSO</B><dd>
The SEE ALSO section lists related entries.
</dl>
<p>
Certain of the standard utilities describe how they can invoke
other utilities or applications, such as by passing a command string
to the command interpreter.
The external influences (STDIN, ENVIRONMENT VARIABLES, and so on)
and external effects (STDOUT, CONSEQUENCES OF ERRORS, and so on)
of such invoked utilities
are not described in the section concerning
the standard utility that invokes them.
</blockquote><hr size=2 noshade>
<center><font size=2>
UNIX &reg; is a registered Trademark of The Open Group.<br>
Copyright &copy; 1997 The Open Group
<br> [ <a href="../index.html">Main Index</a> | <a href="../xshix.html">XSH</a> | <a href="../xcuix.html">XCU</a> | <a href="../xbdix.html">XBD</a> | <a href="../cursesix.html">XCURSES</a> | <a href="../xnsix.html">XNS</a> ]

</font></center><hr size=2 noshade>
</body></html>