Mercurial > repo
changeset 7331:84581528a29e
<oerjan> fetch http://pubs.opengroup.org/onlinepubs/009695399/functions/_Exit.html
| author | HackBot |
|---|---|
| date | Thu, 31 Mar 2016 09:29:50 +0000 |
| parents | 0eae4b049f93 |
| children | 50781dbe0bdb |
| files | _Exit.html |
| diffstat | 1 files changed, 427 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/_Exit.html Thu Mar 31 09:29:50 2016 +0000 @@ -0,0 +1,427 @@ +<!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-2004 IEEE and The Open Group, All Rights Reserved --> +<title>exit</title> +</head> +<body bgcolor="white"> +<script type="text/javascript" language="JavaScript" src="../jscript/codes.js"> +</script> + +<basefont size="3"> <a name="exit"></a> <a name="tag_03_131"></a><!-- exit --> + <!--header start--> +<center><font size="2">The Open Group Base Specifications Issue 6<br> +IEEE Std 1003.1, 2004 Edition<br> +Copyright © 2001-2004 The IEEE and The Open Group, All Rights reserved.</font></center><center><font color="red">A newer edition of this document exists <a href="http://pubs.opengroup.org/onlinepubs/9699919799/" target="_parent">here</a></font></center> + +<!--header end--> +<hr size="2" noshade> +<h4><a name="tag_03_131_01"></a>NAME</h4> + +<blockquote>exit, _Exit, _exit - terminate a process</blockquote> + +<h4><a name="tag_03_131_02"></a>SYNOPSIS</h4> + +<blockquote class="synopsis"> +<p><code><tt>#include <<a href="../basedefs/stdlib.h.html">stdlib.h</a>><br> +<br> + void exit(int</tt> <i>status</i><tt>);<br> + void _Exit(int</tt> <i>status</i><tt>);<br> +<br> +<br> + #include <<a href="../basedefs/unistd.h.html">unistd.h</a>><br> + void _exit(int</tt> <i>status</i><tt>);<br> +</tt></code></p> +</blockquote> + +<h4><a name="tag_03_131_03"></a>DESCRIPTION</h4> + +<blockquote> +<p>For <i>exit</i>() and <i>_Exit</i>(): <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src= +"../images/opt-start.gif" alt="[Option Start]" border="0"> The functionality described on this reference page is aligned with the +ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume +of IEEE Std 1003.1-2001 defers to the ISO C standard. <img src="../images/opt-end.gif" alt="[Option End]" border= +"0"></p> + +<p>The value of <i>status</i> may be 0, EXIT_SUCCESS, EXIT_FAILURE, <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img +src="../images/opt-start.gif" alt="[Option Start]" border="0"> or any other value, though only the least significant 8 bits +(that is, <i>status</i> & 0377) shall be available to a waiting parent process. <img src="../images/opt-end.gif" alt= +"[Option End]" border="0"></p> + +<p>The <i>exit</i>() function shall first call all functions registered by <a href="../functions/atexit.html"><i>atexit</i>()</a>, +in the reverse order of their registration, except that a function is called after any previously registered functions that had +already been called at the time it was registered. Each function is called as many times as it was registered. If, during the call +to any such function, a call to the <a href="../functions/longjmp.html"><i>longjmp</i>()</a> function is made that would terminate +the call to the registered function, the behavior is undefined.</p> + +<p>If a function registered by a call to <a href="../functions/atexit.html"><i>atexit</i>()</a> fails to return, the remaining +registered functions shall not be called and the rest of the <i>exit</i>() processing shall not be completed. If <i>exit</i>() is +called more than once, the behavior is undefined.</p> + +<p>The <i>exit</i>() function shall then flush all open streams with unwritten buffered data, close all open streams, and remove +all files created by <a href="../functions/tmpfile.html"><i>tmpfile</i>()</a>. Finally, control shall be terminated with the +consequences described below.</p> + +<p><sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> The +<i>_Exit</i>() and <i>_exit</i>() functions shall be functionally equivalent. <img src="../images/opt-end.gif" alt="[Option End]" +border="0"></p> + +<p>The <i>_Exit</i>() <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt= +"[Option Start]" border="0"> and <i>_exit</i>() <img src="../images/opt-end.gif" alt="[Option End]" border="0"> functions +shall not call functions registered with <a href="../functions/atexit.html"><i>atexit</i>()</a> nor any registered signal handlers. +Whether open streams are flushed or closed, or temporary files are removed is implementation-defined. Finally, the calling process +is terminated with the consequences described below.</p> + +<p>These functions shall terminate the calling process <sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src= +"../images/opt-start.gif" alt="[Option Start]" border="0"> with the following consequences: <img src="../images/opt-end.gif" +alt="[Option End]" border="0"> <basefont size="2"></p> + +<dl> +<dt><b>Note:</b></dt> + +<dd>These consequences are all extensions to the ISO C standard and are not further CX shaded. However, XSI extensions are +shaded.</dd> +</dl> + +<basefont size="3"> + +<ul> +<li> +<p>All of the file descriptors, directory streams, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src= +"../images/opt-start.gif" alt="[Option Start]" border="0"> conversion descriptors, and message catalog descriptors <img src= +"../images/opt-end.gif" alt="[Option End]" border="0"> open in the calling process shall be closed.</p> +</li> + +<li> +<p>If the parent process of the calling process is executing a <a href="../functions/wait.html"><i>wait</i>()</a> or <a href= +"../functions/waitpid.html"><i>waitpid</i>()</a>, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src= +"../images/opt-start.gif" alt="[Option Start]" border="0"> and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to +SIG_IGN, <img src="../images/opt-end.gif" alt="[Option End]" border="0"> it shall be notified of the calling process' termination +and the low-order eight bits (that is, bits 0377) of <i>status</i> shall be made available to it. If the parent is not waiting, the +child's status shall be made available to it when the parent subsequently executes <a href= +"../functions/wait.html"><i>wait</i>()</a> or <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.</p> + +<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +The semantics of the <a href="../functions/waitid.html"><i>waitid</i>()</a> function shall be equivalent to <a href= +"../functions/wait.html"><i>wait</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p>If the parent process of the calling process is not executing a <a href="../functions/wait.html"><i>wait</i>()</a> or <a href= +"../functions/waitpid.html"><i>waitpid</i>()</a>, <sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src= +"../images/opt-start.gif" alt="[Option Start]" border="0"> and has neither set its SA_NOCLDWAIT flag nor set SIGCHLD to +SIG_IGN, <img src="../images/opt-end.gif" alt="[Option End]" border="0"> the calling process shall be transformed into a <i>zombie +process</i>. A <i>zombie process</i> is an inactive process and it shall be deleted at some later time when its parent process +executes <a href="../functions/wait.html"><i>wait</i>()</a> or <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.</p> + +<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +The semantics of the <a href="../functions/waitid.html"><i>waitid</i>()</a> function shall be equivalent to <a href= +"../functions/wait.html"><i>wait</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p>Termination of a process does not directly terminate its children. The sending of a SIGHUP signal as described below indirectly +terminates children in some circumstances.</p> +</li> + +<li> +<p>Either:</p> + +<p>If the implementation supports the SIGCHLD signal, a SIGCHLD shall be sent to the parent process.</p> + +<p>Or:</p> + +<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +If the parent process has set its SA_NOCLDWAIT flag, or set SIGCHLD to SIG_IGN, the status shall be discarded, and the lifetime of +the calling process shall end immediately. If SA_NOCLDWAIT is set, it is implementation-defined whether a SIGCHLD signal is sent to +the parent process. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p>The parent process ID of all of the calling process' existing child processes and zombie processes shall be set to the process +ID of an implementation-defined system process. That is, these processes shall be inherited by a special system process.</p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +Each attached shared-memory segment is detached and the value of <i>shm_nattch</i> (see <a href= +"../functions/shmget.html"><i>shmget</i>()</a>) in the data structure associated with its shared memory ID shall be decremented by +1. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +For each semaphore for which the calling process has set a <i>semadj</i> value (see <a href="semop.html"><i>semop</i>()</a> ), that +value shall be added to the <i>semval</i> of the specified semaphore. <img src="../images/opt-end.gif" alt="[Option End]" border= +"0"></p> +</li> + +<li> +<p>If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the +controlling terminal belonging to the calling process.</p> +</li> + +<li> +<p>If the process is a controlling process, the controlling terminal associated with the session shall be disassociated from the +session, allowing it to be acquired by a new controlling process.</p> +</li> + +<li> +<p>If the exit of the process causes a process group to become orphaned, and if any member of the newly-orphaned process group is +stopped, then a SIGHUP signal followed by a SIGCONT signal shall be sent to each process in the newly-orphaned process group.</p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('SEM')">SEM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +All open named semaphores in the calling process shall be closed as if by appropriate calls to <a href= +"../functions/sem_close.html"><i>sem_close</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('ML')">ML</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> Any +memory locks established by the process via calls to <a href="../functions/mlockall.html"><i>mlockall</i>()</a> or <a href= +"../functions/mlock.html"><i>mlock</i>()</a> shall be removed. If locked pages in the address space of the calling process are also +mapped into the address spaces of other processes and are locked by those processes, the locks established by the other processes +shall be unaffected by the call by this process to <i>_Exit</i>() or <i>_exit</i>(). <img src="../images/opt-end.gif" alt= +"[Option End]" border="0"></p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('MF')">MF|SHM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +Memory mappings that were created in the process shall be unmapped before the process is destroyed. <img src= +"../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('TYM')">TYM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +Any blocks of typed memory that were mapped in the calling process shall be unmapped, as if <a href= +"../functions/munmap.html"><i>munmap</i>()</a> was implicitly called to unmap them. <img src="../images/opt-end.gif" alt= +"[Option End]" border="0"></p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('MSG')">MSG</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +All open message queue descriptors in the calling process shall be closed as if by appropriate calls to <a href= +"../functions/mq_close.html"><i>mq_close</i>()</a>. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('AIO')">AIO</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +Any outstanding cancelable asynchronous I/O operations may be canceled. Those asynchronous I/O operations that are not canceled +shall complete as if the <i>_Exit</i>() or <i>_exit</i>() operation had not yet occurred, but any associated signal notifications +shall be suppressed. The <i>_Exit</i>() or <i>_exit</i>() operation may block awaiting such I/O completion. Whether any I/O is +canceled, and which I/O may be canceled upon <i>_Exit</i>() or <i>_exit</i>(), is implementation-defined. <img src= +"../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> + +<li> +<p>Threads terminated by a call to <i>_Exit</i>() or <i>_exit</i>() shall not invoke their cancellation cleanup handlers or +per-thread data destructors.</p> +</li> + +<li> +<p><sup>[<a href="javascript:open_code('TRC')">TRC</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> +If the calling process is a trace controller process, any trace streams that were created by the calling process shall be shut down +as described by the <a href="../functions/posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a> function, and any process' +mapping of trace event names to trace event type identifiers built for these trace streams may be deallocated. <img src= +"../images/opt-end.gif" alt="[Option End]" border="0"></p> +</li> +</ul> +</blockquote> + +<h4><a name="tag_03_131_04"></a>RETURN VALUE</h4> + +<blockquote> +<p>These functions do not return.</p> +</blockquote> + +<h4><a name="tag_03_131_05"></a>ERRORS</h4> + +<blockquote> +<p>No errors are defined.</p> +</blockquote> + +<hr> +<div class="box"><em>The following sections are informative.</em></div> + +<h4><a name="tag_03_131_06"></a>EXAMPLES</h4> + +<blockquote> +<p>None.</p> +</blockquote> + +<h4><a name="tag_03_131_07"></a>APPLICATION USAGE</h4> + +<blockquote> +<p>Normally applications should use <i>exit</i>() rather than <i>_Exit</i>() or <i>_exit</i>().</p> +</blockquote> + +<h4><a name="tag_03_131_08"></a>RATIONALE</h4> + +<blockquote> +<h5><a name="tag_03_131_08_01"></a>Process Termination</h5> + +<p>Early proposals drew a distinction between normal and abnormal process termination. Abnormal termination was caused only by +certain signals and resulted in implementation-defined "actions", as discussed below. Subsequent proposals distinguished three +types of termination: <i>normal termination</i> (as in the current specification), <i>simple abnormal termination</i>, and +<i>abnormal termination with actions</i>. Again the distinction between the two types of abnormal termination was that they were +caused by different signals and that implementation-defined actions would result in the latter case. Given that these actions were +completely implementation-defined, the early proposals were only saying when the actions could occur and how their occurrence could +be detected, but not what they were. This was of little or no use to conforming applications, and thus the distinction is not made +in this volume of IEEE Std 1003.1-2001.</p> + +<p>The implementation-defined actions usually include, in most historical implementations, the creation of a file named <b>core</b> +in the current working directory of the process. This file contains an image of the memory of the process, together with +descriptive information about the process, perhaps sufficient to reconstruct the state of the process at the receipt of the +signal.</p> + +<p>There is a potential security problem in creating a <b>core</b> file if the process was set-user-ID and the current user is not +the owner of the program, if the process was set-group-ID and none of the user's groups match the group of the program, or if the +user does not have permission to write in the current directory. In this situation, an implementation either should not create a +<b>core</b> file or should make it unreadable by the user.</p> + +<p>Despite the silence of this volume of IEEE Std 1003.1-2001 on this feature, applications are advised not to create +files named <b>core</b> because of potential conflicts in many implementations. Some implementations use a name other than +<b>core</b> for the file; for example, by appending the process ID to the filename.</p> + +<h5><a name="tag_03_131_08_02"></a>Terminating a Process</h5> + +<p>It is important that the consequences of process termination as described occur regardless of whether the process called +<i>_exit</i>() (perhaps indirectly through <i>exit</i>()) or instead was terminated due to a signal or for some other reason. Note +that in the specific case of <i>exit</i>() this means that the <i>status</i> argument to <i>exit</i>() is treated in the same way +as the <i>status</i> argument to <i>_exit</i>().</p> + +<p>A language other than C may have other termination primitives than the C-language <i>exit</i>() function, and programs written +in such a language should use its native termination primitives, but those should have as part of their function the behavior of +<i>_exit</i>() as described. Implementations in languages other than C are outside the scope of this version of this volume of +IEEE Std 1003.1-2001, however.</p> + +<p>As required by the ISO C standard, using <b>return</b> from <i>main</i>() has the same behavior (other than with respect to +language scope issues) as calling <i>exit</i>() with the returned value. Reaching the end of the <i>main</i>() function has the +same behavior as calling <i>exit</i>(0).</p> + +<p>A value of zero (or EXIT_SUCCESS, which is required to be zero) for the argument <i>status</i> conventionally indicates +successful termination. This corresponds to the specification for <i>exit</i>() in the ISO C standard. The convention is +followed by utilities such as <a href="../utilities/make.html"><i>make</i></a> and various shells, which interpret a zero status +from a child process as success. For this reason, applications should not call <i>exit</i>(0) or <i>_exit</i>(0) when they +terminate unsuccessfully; for example, in signal-catching functions.</p> + +<p>Historically, the implementation-defined process that inherits children whose parents have terminated without waiting on them is +called <i>init</i> and has a process ID of 1.</p> + +<p>The sending of a SIGHUP to the foreground process group when a controlling process terminates corresponds to somewhat different +historical implementations. In System V, the kernel sends a SIGHUP on termination of (essentially) a controlling process. In 4.2 +BSD, the kernel does not send SIGHUP in a case like this, but the termination of a controlling process is usually noticed by a +system daemon, which arranges to send a SIGHUP to the foreground process group with the <i>vhangup</i>() function. However, in 4.2 +BSD, due to the behavior of the shells that support job control, the controlling process is usually a shell with no other processes +in its process group. Thus, a change to make <i>_exit</i>() behave this way in such systems should not cause problems with existing +applications.</p> + +<p>The termination of a process may cause a process group to become orphaned in either of two ways. The connection of a process +group to its parent(s) outside of the group depends on both the parents and their children. Thus, a process group may be orphaned +by the termination of the last connecting parent process outside of the group or by the termination of the last direct descendant +of the parent process(es). In either case, if the termination of a process causes a process group to become orphaned, processes +within the group are disconnected from their job control shell, which no longer has any information on the existence of the process +group. Stopped processes within the group would languish forever. In order to avoid this problem, newly orphaned process groups +that contain stopped processes are sent a SIGHUP signal and a SIGCONT signal to indicate that they have been disconnected from +their session. The SIGHUP signal causes the process group members to terminate unless they are catching or ignoring SIGHUP. Under +most circumstances, all of the members of the process group are stopped if any of them are stopped.</p> + +<p>The action of sending a SIGHUP and a SIGCONT signal to members of a newly orphaned process group is similar to the action of 4.2 +BSD, which sends SIGHUP and SIGCONT to each stopped child of an exiting process. If such children exit in response to the SIGHUP, +any additional descendants receive similar treatment at that time. In this volume of IEEE Std 1003.1-2001, the signals +are sent to the entire process group at the same time. Also, in this volume of IEEE Std 1003.1-2001, but not in 4.2 BSD, +stopped processes may be orphaned, but may be members of a process group that is not orphaned; therefore, the action taken at +<i>_exit</i>() must consider processes other than child processes.</p> + +<p>It is possible for a process group to be orphaned by a call to <a href="../functions/setpgid.html"><i>setpgid</i>()</a> or <a +href="../functions/setsid.html"><i>setsid</i>()</a>, as well as by process termination. This volume of +IEEE Std 1003.1-2001 does not require sending SIGHUP and SIGCONT in those cases, because, unlike process termination, +those cases are not caused accidentally by applications that are unaware of job control. An implementation can choose to send +SIGHUP and SIGCONT in those cases as an extension; such an extension must be documented as required in <a href= +"../basedefs/signal.h.html"><i><signal.h></i></a>.</p> + +<p>The ISO/IEC 9899:1999 standard adds the <i>_Exit</i>() function that results in immediate program termination without +triggering signals or <a href="../functions/atexit.html"><i>atexit</i>()</a>-registered functions. In +IEEE Std 1003.1-2001, this is equivalent to the <i>_exit</i>() function.</p> +</blockquote> + +<h4><a name="tag_03_131_09"></a>FUTURE DIRECTIONS</h4> + +<blockquote> +<p>None.</p> +</blockquote> + +<h4><a name="tag_03_131_10"></a>SEE ALSO</h4> + +<blockquote> +<p><a href="atexit.html"><i>atexit</i>()</a>, <a href="close.html"><i>close</i>()</a>, <a href="fclose.html"><i>fclose</i>()</a> +, <a href="longjmp.html"><i>longjmp</i>()</a>, <a href="posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a>, <a href= +"posix_trace_trid_eventid_open.html"><i>posix_trace_trid_eventid_open</i>()</a>, <a href="semop.html"><i>semop</i>()</a>, <a +href="shmget.html"><i>shmget</i>()</a>, <a href="sigaction.html"><i>sigaction</i>()</a>, <a href="wait.html"><i>wait</i>()</a>, +<a href="waitid.html"><i>waitid</i>()</a>, <a href="waitpid.html"><i>waitpid</i>()</a>, the Base Definitions volume of +IEEE Std 1003.1-2001, <a href="../basedefs/stdlib.h.html"><i><stdlib.h></i></a>, <a href= +"../basedefs/unistd.h.html"><i><unistd.h></i></a></p> +</blockquote> + +<h4><a name="tag_03_131_11"></a>CHANGE HISTORY</h4> + +<blockquote> +<p>First released in Issue 1. Derived from Issue 1 of the SVID.</p> +</blockquote> + +<h4><a name="tag_03_131_12"></a>Issue 5</h4> + +<blockquote> +<p>The DESCRIPTION is updated for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.</p> + +<p>Interactions with the SA_NOCLDWAIT flag and SIGCHLD signal are further clarified.</p> + +<p>The values of <i>status</i> from <i>exit</i>() are better described.</p> +</blockquote> + +<h4><a name="tag_03_131_13"></a>Issue 6</h4> + +<blockquote> +<p>Extensions beyond the ISO C standard are marked.</p> + +<p>The DESCRIPTION is updated for alignment with IEEE Std 1003.1j-2000 by adding semantics for typed memory.</p> + +<p>The following changes are made for alignment with the ISO/IEC 9899:1999 standard:</p> + +<ul> +<li> +<p>The <i>_Exit</i>() function is included.</p> +</li> + +<li> +<p>The DESCRIPTION is updated.</p> +</li> +</ul> + +<p>The description of tracing semantics is added for alignment with IEEE Std 1003.1q-2000.</p> + +<p>References to the <i>wait3</i>() function are removed.</p> + +<p>IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/16 is applied, correcting grammar in the DESCRIPTION.</p> +</blockquote> + +<div class="box"><em>End of informative text.</em></div> + +<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> +