940 lines
44 KiB
HTML
940 lines
44 KiB
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 The Open Group, All Rights Reserved -->
|
|
<title>exec</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
<script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
|
|
</script>
|
|
|
|
<basefont size="3"> <a name="exec"></a> <a name="tag_03_130"></a><!-- exec -->
|
|
<!--header start-->
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
|
|
|
|
<!--header end-->
|
|
<hr size="2" noshade>
|
|
<h4><a name="tag_03_130_01"></a>NAME</h4>
|
|
|
|
<blockquote>environ, execl, execv, execle, execve, execlp, execvp - execute a file</blockquote>
|
|
|
|
<h4><a name="tag_03_130_02"></a>SYNOPSIS</h4>
|
|
|
|
<blockquote class="synopsis">
|
|
<p><code><tt>#include <<a href="../basedefs/unistd.h.html">unistd.h</a>><br>
|
|
<br>
|
|
extern char **environ;<br>
|
|
int execl(const char *</tt><i>path</i><tt>, const char *</tt><i>arg0</i><tt>, ... /*, (char *)0 */);<br>
|
|
int execv(const char *</tt><i>path</i><tt>, char *const</tt> <i>argv</i><tt>[]);<br>
|
|
int execle(const char *</tt><i>path</i><tt>, const char *</tt><i>arg0</i><tt>, ... /*,<br>
|
|
(char *)0, char *const</tt> <i>envp</i><tt>[]*/);<br>
|
|
int execve(const char *</tt><i>path</i><tt>, char *const</tt> <i>argv</i><tt>[], char *const</tt> <i>envp</i><tt>[]);<br>
|
|
int execlp(const char *</tt><i>file</i><tt>, const char *</tt><i>arg0</i><tt>, ... /*, (char *)0 */);<br>
|
|
int execvp(const char *</tt><i>file</i><tt>, char *const</tt> <i>argv</i><tt>[]);<br>
|
|
</tt></code></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_03"></a>DESCRIPTION</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>exec</i> family of functions shall replace the current process image with a new process image. The new image shall be
|
|
constructed from a regular, executable file called the <i>new process image file</i>. There shall be no return from a successful
|
|
<i>exec</i>, because the calling process image is overlaid by the new process image.</p>
|
|
|
|
<p>When a C-language program is executed as a result of this call, it shall be entered as a C-language function call as
|
|
follows:</p>
|
|
|
|
<pre>
|
|
<tt>int main (</tt><i>int argc, char *argv</i><tt>[]);
|
|
</tt>
|
|
</pre>
|
|
|
|
<p>where <i>argc</i> is the argument count and <i>argv</i> is an array of character pointers to the arguments themselves. In
|
|
addition, the following variable:</p>
|
|
|
|
<pre>
|
|
<tt>extern char **environ;
|
|
</tt>
|
|
</pre>
|
|
|
|
<p>is initialized as a pointer to an array of character pointers to the environment strings. The <i>argv</i> and <i>environ</i>
|
|
arrays are each terminated by a null pointer. The null pointer terminating the <i>argv</i> array is not counted in <i>argc</i>.</p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('THR')">THR</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Conforming multi-threaded applications shall not use the <i>environ</i> variable to access or modify any environment variable while
|
|
any other thread is concurrently modifying any environment variable. A call to any function dependent on any environment variable
|
|
shall be considered a use of the <i>environ</i> variable to access that environment variable. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
|
|
<p>The arguments specified by a program with one of the <i>exec</i> functions shall be passed on to the new process image in the
|
|
corresponding <i>main</i>() arguments.</p>
|
|
|
|
<p>The argument <i>path</i> points to a pathname that identifies the new process image file.</p>
|
|
|
|
<p>The argument <i>file</i> is used to construct a pathname that identifies the new process image file. If the <i>file</i> argument
|
|
contains a slash character, the <i>file</i> argument shall be used as the pathname for this file. Otherwise, the path prefix for
|
|
this file is obtained by a search of the directories passed as the environment variable <i>PATH</i> (see the Base Definitions
|
|
volume of IEEE Std 1003.1-2001, <a href="../basedefs/xbd_chap08.html">Chapter 8, Environment Variables</a>). If this
|
|
environment variable is not present, the results of the search are implementation-defined.</p>
|
|
|
|
<p>There are two distinct ways in which the contents of the process image file may cause the execution to fail, distinguished by
|
|
the setting of <i>errno</i> to either [ENOEXEC] or [EINVAL] (see the ERRORS section). In the cases where the other members of the
|
|
<i>exec</i> family of functions would fail and set <i>errno</i> to [ENOEXEC], the <i>execlp</i>() and <i>execvp</i>() functions
|
|
shall execute a command interpreter and the environment of the executed command shall be as if the process invoked the <a href=
|
|
"../utilities/sh.html"><i>sh</i></a> utility using <i>execl</i>() as follows:</p>
|
|
|
|
<pre>
|
|
<tt>execl(<shell path>, arg0, file, arg1, ..., (char *)0);
|
|
</tt>
|
|
</pre>
|
|
|
|
<p>where <<i>shell path</i>> is an unspecified pathname for the <a href="../utilities/sh.html"><i>sh</i></a> utility,
|
|
<i>file</i> is the process image file, and for <i>execvp</i>(), where <i>arg</i>0, <i>arg</i>1, and so on correspond to the values
|
|
passed to <i>execvp</i>() in <i>argv</i>[0], <i>argv</i>[1], and so on.</p>
|
|
|
|
<p>The arguments represented by <i>arg0</i>,... are pointers to null-terminated character strings. These strings shall constitute
|
|
the argument list available to the new process image. The list is terminated by a null pointer. The argument <i>arg0</i> should
|
|
point to a filename that is associated with the process being started by one of the <i>exec</i> functions.</p>
|
|
|
|
<p>The argument <i>argv</i> is an array of character pointers to null-terminated strings. The application shall ensure that the
|
|
last member of this array is a null pointer. These strings shall constitute the argument list available to the new process image.
|
|
The value in <i>argv</i>[0] should point to a filename that is associated with the process being started by one of the <i>exec</i>
|
|
functions.</p>
|
|
|
|
<p>The argument <i>envp</i> is an array of character pointers to null-terminated strings. These strings shall constitute the
|
|
environment for the new process image. The <i>envp</i> array is terminated by a null pointer.</p>
|
|
|
|
<p>For those forms not containing an <i>envp</i> pointer ( <i>execl</i>(), <i>execv</i>(), <i>execlp</i>(), and <i>execvp</i>()),
|
|
the environment for the new process image shall be taken from the external variable <i>environ</i> in the calling process.</p>
|
|
|
|
<p>The number of bytes available for the new process' combined argument and environment lists is {ARG_MAX}. It is
|
|
implementation-defined whether null terminators, pointers, and/or any alignment bytes are included in this total.</p>
|
|
|
|
<p>File descriptors open in the calling process image shall remain open in the new process image, except for those whose close-on-
|
|
<i>exec</i> flag FD_CLOEXEC is set. For those file descriptors that remain open, all attributes of the open file description remain
|
|
unchanged. For any file descriptor that is closed for this reason, file locks are removed as a result of the close as described in
|
|
<a href="close.html"><i>close</i>()</a> . Locks that are not removed by closing of file descriptors remain unchanged.</p>
|
|
|
|
<p>Directory streams open in the calling process image shall be closed in the new process image.</p>
|
|
|
|
<p>The state of the floating-point environment in the new process image shall be set to the default.</p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The state of conversion descriptors and message catalog descriptors in the new process image is undefined. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"> For the new process image, the equivalent of:</p>
|
|
|
|
<pre>
|
|
<tt>setlocale(LC_ALL, "C")
|
|
</tt>
|
|
</pre>
|
|
|
|
<p>shall be executed at start-up.</p>
|
|
|
|
<p>Signals set to the default action (SIG_DFL) in the calling process image shall be set to the default action in the new process
|
|
image. Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling process image shall be set to be ignored by the new
|
|
process image. Signals set to be caught by the calling process image shall be set to the default action in the new process image
|
|
(see <a href="../basedefs/signal.h.html"><i><signal.h></i></a>). If the SIGCHLD signal is set to be ignored by the calling
|
|
process image, it is unspecified whether the SIGCHLD signal is set to be ignored or to the default action in the new process image.
|
|
<sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
After a successful call to any of the <i>exec</i> functions, alternate signal stacks are not preserved and the SA_ONSTACK
|
|
flag shall be cleared for all signals. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p>After a successful call to any of the <i>exec</i> functions, any functions previously registered by <a href=
|
|
"../functions/atexit.html"><i>atexit</i>()</a> are no longer registered.</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 ST_NOSUID bit is set for the file system containing the new process image file, then the effective user ID, effective group
|
|
ID, saved set-user-ID, and saved set-group-ID are unchanged in the new process image. Otherwise, <img src="../images/opt-end.gif"
|
|
alt="[Option End]" border="0"> if the set-user-ID mode bit of the new process image file is set, the effective user ID of the new
|
|
process image shall be set to the user ID of the new process image file. Similarly, if the set-group-ID mode bit of the new process
|
|
image file is set, the effective group ID of the new process image shall be set to the group ID of the new process image file. The
|
|
real user ID, real group ID, and supplementary group IDs of the new process image shall remain the same as those of the calling
|
|
process image. The effective user ID and effective group ID of the new process image shall be saved (as the saved set-user-ID and
|
|
the saved set-group-ID) for use by <a href="../functions/setuid.html"><i>setuid</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">
|
|
Any shared memory segments attached to the calling process image shall not be attached to the new process image. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('SEM')">SEM</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Any named semaphores open 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>
|
|
|
|
<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 are 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>
|
|
|
|
<p><sup>[<a href="javascript:open_code('ML')">ML</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Memory locks established by the calling 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 the <i>exec</i> function. If the <i>exec</i> function fails, the effect on
|
|
memory locks is unspecified. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<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 created in the process are unmapped before the address space is rebuilt for the new process image. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('PS')">PS</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0"> For
|
|
the SCHED_FIFO and SCHED_RR scheduling policies, the policy and priority settings shall not be changed by a call to an <i>exec</i>
|
|
function. For other scheduling policies, the policy and priority settings on <i>exec</i> are implementation-defined. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('TMR')">TMR</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Per-process timers created by the calling process shall be deleted before replacing the current process image with the new process
|
|
image. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<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 described in <a href=
|
|
"mq_close.html"><i>mq_close</i>()</a> . <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('AIO')">AIO</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Any outstanding asynchronous I/O operations may be canceled. Those asynchronous I/O operations that are not canceled shall complete
|
|
as if the <i>exec</i> function had not yet occurred, but any associated signal notifications shall be suppressed. It is unspecified
|
|
whether the <i>exec</i> function itself blocks awaiting such I/O completion. In no event, however, shall the new process image
|
|
created by the <i>exec</i> function be affected by the presence of outstanding asynchronous I/O operations at the time the
|
|
<i>exec</i> function is called. Whether any I/O is canceled, and which I/O may be canceled upon <i>exec</i>, is
|
|
implementation-defined. <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('CPT')">CPT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The new process image shall inherit the CPU-time clock of the calling process image. This inheritance means that the process
|
|
CPU-time clock of the process being <i>exec</i>-ed shall not be reinitialized or altered as a result of the <i>exec</i> function
|
|
other than to reflect the time spent by the process executing the <i>exec</i> function itself. <img src="../images/opt-end.gif"
|
|
alt="[Option End]" border="0"></p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('TCT')">TCT</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The initial value of the CPU-time clock of the initial thread of the new process image shall be set to zero. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<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 being traced, the new process image shall continue to be traced into the same trace stream as the
|
|
original process image, but the new process image shall not inherit the mapping of trace event names to trace event type
|
|
identifiers that was defined by calls to the <a href=
|
|
"../functions/posix_trace_eventid_open.html"><i>posix_trace_eventid_open</i>()</a> or the <a href=
|
|
"../functions/posix_trace_trid_eventid_open.html"><i>posix_trace_trid_eventid_open</i>()</a> functions in the calling process
|
|
image.</p>
|
|
|
|
<p>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 in the <a href="../functions/posix_trace_shutdown.html"><i>posix_trace_shutdown</i>()</a> function. <img src=
|
|
"../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
|
|
<p>The new process shall inherit at least the following attributes from the calling process image:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
Nice value (see <a href="nice.html"><i>nice</i>()</a> ) <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">
|
|
<i>semadj</i> values (see <a href="semop.html"><i>semop</i>()</a> ) <img src="../images/opt-end.gif" alt="[Option End]" border=
|
|
"0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Process ID</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Parent process ID</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Process group ID</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Session membership</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Real user ID</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Real group ID</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Supplementary group IDs</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Time left until an alarm clock signal (see <a href="alarm.html"><i>alarm</i>()</a> )</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Current working directory</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Root directory</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>File mode creation mask (see <a href="umask.html"><i>umask</i>()</a> )</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">
|
|
File size limit (see <a href="ulimit.html"><i>ulimit</i>()</a> ) <img src="../images/opt-end.gif" alt="[Option End]" border=
|
|
"0"></p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Process signal mask (see <a href="sigprocmask.html"><i>sigprocmask</i>()</a> )</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Pending signal (see <a href="sigpending.html"><i>sigpending</i>()</a> )</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><i>tms_utime</i>, <i>tms_stime</i>, <i>tms_cutime</i>, and <i>tms_cstime</i> (see <a href="times.html"><i>times</i>()</a> )</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">
|
|
Resource limits <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">
|
|
Controlling terminal <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">
|
|
Interval timers <img src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>All other process attributes defined in this volume of IEEE Std 1003.1-2001 shall be the same in the new and old
|
|
process images. The inheritance of process attributes not defined by this volume of IEEE Std 1003.1-2001 is
|
|
implementation-defined.</p>
|
|
|
|
<p>A call to any <i>exec</i> function from a process with more than one thread shall result in all threads being terminated and the
|
|
new executable image being loaded and executed. No destructor functions shall be called.</p>
|
|
|
|
<p>Upon successful completion, the <i>exec</i> functions shall mark for update the <i>st_atime</i> field of the file. If an
|
|
<i>exec</i> function failed but was able to locate the process image file, whether the <i>st_atime</i> field is marked for update
|
|
is unspecified. Should the <i>exec</i> function succeed, the process image file shall be considered to have been opened with <a
|
|
href="../functions/open.html"><i>open</i>()</a>. The corresponding <a href="../functions/close.html"><i>close</i>()</a> shall be
|
|
considered to occur at a time after this open, but before process termination or successful completion of a subsequent call to one
|
|
of the <i>exec</i> functions, <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a>, or <a href=
|
|
"../functions/posix_spawnp.html"><i>posix_spawnp</i>()</a>. The <i>argv</i>[] and <i>envp</i>[] arrays of pointers and the strings
|
|
to which those arrays point shall not be modified by a call to one of the <i>exec</i> functions, except as a consequence of
|
|
replacing the process image.</p>
|
|
|
|
<p><sup>[<a href="javascript:open_code('XSI')">XSI</a>]</sup> <img src="../images/opt-start.gif" alt="[Option Start]" border="0">
|
|
The saved resource limits in the new process image are set to be a copy of the process' corresponding hard and soft limits. <img
|
|
src="../images/opt-end.gif" alt="[Option End]" border="0"></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_04"></a>RETURN VALUE</h4>
|
|
|
|
<blockquote>
|
|
<p>If one of the <i>exec</i> functions returns to the calling process image, an error has occurred; the return value shall be -1,
|
|
and <i>errno</i> shall be set to indicate the error.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_05"></a>ERRORS</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>exec</i> functions shall fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[E2BIG]</dt>
|
|
|
|
<dd>The number of bytes used by the new process image's argument list and environment list is greater than the system-imposed limit
|
|
of {ARG_MAX} bytes.</dd>
|
|
|
|
<dt>[EACCES]</dt>
|
|
|
|
<dd>Search permission is denied for a directory listed in the new process image file's path prefix, or the new process image file
|
|
denies execution permission, or the new process image file is not a regular file and the implementation does not support execution
|
|
of files of its type.</dd>
|
|
|
|
<dt>[EINVAL]</dt>
|
|
|
|
<dd>The new process image file has the appropriate permission and has a recognized executable binary format, but the system does
|
|
not support execution of a file with this format.</dd>
|
|
|
|
<dt>[ELOOP]</dt>
|
|
|
|
<dd>A loop exists in symbolic links encountered during resolution of the <i>path</i> or <i>file</i> argument.</dd>
|
|
|
|
<dt>[ENAMETOOLONG]</dt>
|
|
|
|
<dd>
|
|
The length of the <i>path</i> or <i>file</i> arguments exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}.</dd>
|
|
|
|
<dt>[ENOENT]</dt>
|
|
|
|
<dd>A component of <i>path</i> or <i>file</i> does not name an existing file or <i>path</i> or <i>file</i> is an empty string.</dd>
|
|
|
|
<dt>[ENOTDIR]</dt>
|
|
|
|
<dd>A component of the new process image file's path prefix is not a directory.</dd>
|
|
</dl>
|
|
|
|
<p>The <i>exec</i> functions, except for <i>execlp</i>() and <i>execvp</i>(), shall fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[ENOEXEC]</dt>
|
|
|
|
<dd>The new process image file has the appropriate access permission but has an unrecognized format.</dd>
|
|
</dl>
|
|
|
|
<p>The <i>exec</i> functions may fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[ELOOP]</dt>
|
|
|
|
<dd>More than {SYMLOOP_MAX} symbolic links were encountered during resolution of the <i>path</i> or <i>file</i> argument.</dd>
|
|
|
|
<dt>[ENAMETOOLONG]</dt>
|
|
|
|
<dd>
|
|
As a result of encountering a symbolic link in resolution of the <i>path</i> argument, the length of the substituted pathname
|
|
string exceeded {PATH_MAX}.</dd>
|
|
|
|
<dt>[ENOMEM]</dt>
|
|
|
|
<dd>The new process image requires more memory than is allowed by the hardware or system-imposed memory management
|
|
constraints.</dd>
|
|
|
|
<dt>[ETXTBSY]</dt>
|
|
|
|
<dd>The new process image file is a pure procedure (shared text) file that is currently open for writing by some process.</dd>
|
|
</dl>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<div class="box"><em>The following sections are informative.</em></div>
|
|
|
|
<h4><a name="tag_03_130_06"></a>EXAMPLES</h4>
|
|
|
|
<blockquote>
|
|
<h5><a name="tag_03_130_06_01"></a>Using execl()</h5>
|
|
|
|
<p>The following example executes the <a href="../utilities/ls.html"><i>ls</i></a> command, specifying the pathname of the
|
|
executable ( <b>/bin/ls</b>) and using arguments supplied directly to the command to produce single-column output.</p>
|
|
|
|
<pre>
|
|
<tt>#include <unistd.h>
|
|
<br>
|
|
int ret;
|
|
...
|
|
ret = execl ("/bin/ls", "ls", "-1", (char *)0);
|
|
</tt>
|
|
</pre>
|
|
|
|
<h5><a name="tag_03_130_06_02"></a>Using execle()</h5>
|
|
|
|
<p>The following example is similar to <a href="#tag_03_130_06_01">Using execl()</a> . In addition, it specifies the environment
|
|
for the new process image using the <i>env</i> argument.</p>
|
|
|
|
<pre>
|
|
<tt>#include <unistd.h>
|
|
<br>
|
|
int ret;
|
|
char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
|
|
...
|
|
ret = execle ("/bin/ls", "ls", "-l", (char *)0, env);
|
|
</tt>
|
|
</pre>
|
|
|
|
<h5><a name="tag_03_130_06_03"></a>Using execlp()</h5>
|
|
|
|
<p>The following example searches for the location of the <a href="../utilities/ls.html"><i>ls</i></a> command among the
|
|
directories specified by the <i>PATH</i> environment variable.</p>
|
|
|
|
<pre>
|
|
<tt>#include <unistd.h>
|
|
<br>
|
|
int ret;
|
|
...
|
|
ret = execlp ("ls", "ls", "-l", (char *)0);
|
|
</tt>
|
|
</pre>
|
|
|
|
<h5><a name="tag_03_130_06_04"></a>Using execv()</h5>
|
|
|
|
<p>The following example passes arguments to the <a href="../utilities/ls.html"><i>ls</i></a> command in the <i>cmd</i> array.</p>
|
|
|
|
<pre>
|
|
<tt>#include <unistd.h>
|
|
<br>
|
|
int ret;
|
|
char *cmd[] = { "ls", "-l", (char *)0 };
|
|
...
|
|
ret = execv ("/bin/ls", cmd);
|
|
</tt>
|
|
</pre>
|
|
|
|
<h5><a name="tag_03_130_06_05"></a>Using execve()</h5>
|
|
|
|
<p>The following example passes arguments to the <a href="../utilities/ls.html"><i>ls</i></a> command in the <i>cmd</i> array, and
|
|
specifies the environment for the new process image using the <i>env</i> argument.</p>
|
|
|
|
<pre>
|
|
<tt>#include <unistd.h>
|
|
<br>
|
|
int ret;
|
|
char *cmd[] = { "ls", "-l", (char *)0 };
|
|
char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
|
|
...
|
|
ret = execve ("/bin/ls", cmd, env);
|
|
</tt>
|
|
</pre>
|
|
|
|
<h5><a name="tag_03_130_06_06"></a>Using execvp()</h5>
|
|
|
|
<p>The following example searches for the location of the <a href="../utilities/ls.html"><i>ls</i></a> command among the
|
|
directories specified by the <i>PATH</i> environment variable, and passes arguments to the <a href=
|
|
"../utilities/ls.html"><i>ls</i></a> command in the <i>cmd</i> array.</p>
|
|
|
|
<pre>
|
|
<tt>#include <unistd.h>
|
|
<br>
|
|
int ret;
|
|
char *cmd[] = { "ls", "-l", (char *)0 };
|
|
...
|
|
ret = execvp ("ls", cmd);
|
|
</tt>
|
|
</pre>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_07"></a>APPLICATION USAGE</h4>
|
|
|
|
<blockquote>
|
|
<p>As the state of conversion descriptors and message catalog descriptors in the new process image is undefined, conforming
|
|
applications should not rely on their use and should close them prior to calling one of the <i>exec</i> functions.</p>
|
|
|
|
<p>Applications that require other than the default POSIX locale should call <a href=
|
|
"../functions/setlocale.html"><i>setlocale</i>()</a> with the appropriate parameters to establish the locale of the new
|
|
process.</p>
|
|
|
|
<p>The <i>environ</i> array should not be accessed directly by the application.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_08"></a>RATIONALE</h4>
|
|
|
|
<blockquote>
|
|
<p>Early proposals required that the value of <i>argc</i> passed to <i>main</i>() be "one or greater". This was driven by the
|
|
same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no
|
|
arguments are supplied to the caller of the <i>exec</i> functions. This requirement was removed from the ISO C standard and
|
|
subsequently removed from this volume of IEEE Std 1003.1-2001 as well. The wording, in particular the use of the word
|
|
<i>should</i>, requires a Strictly Conforming POSIX Application to pass at least one argument to the <i>exec</i> function, thus
|
|
guaranteeing that <i>argc</i> be one or greater when invoked by such an application. In fact, this is good practice, since many
|
|
existing applications reference <i>argv</i>[0] without first checking the value of <i>argc</i>.</p>
|
|
|
|
<p>The requirement on a Strictly Conforming POSIX Application also states that the value passed as the first argument be a filename
|
|
associated with the process being started. Although some existing applications pass a pathname rather than a filename in some
|
|
circumstances, a filename is more generally useful, since the common usage of <i>argv</i>[0] is in printing diagnostics. In some
|
|
cases the filename passed is not the actual filename of the file; for example, many implementations of the <i>login</i> utility use
|
|
a convention of prefixing a hyphen ( <tt>'-'</tt> ) to the actual filename, which indicates to the command interpreter being
|
|
invoked that it is a "login shell".</p>
|
|
|
|
<p>Historically there have been two ways that implementations can <i>exec</i> shell scripts.</p>
|
|
|
|
<p>One common historical implementation is that the <i>execl</i>(), <i>execv</i>(), <i>execle</i>(), and <i>execve</i>() functions
|
|
return an [ENOEXEC] error for any file not recognizable as executable, including a shell script. When the <i>execlp</i>() and
|
|
<i>execvp</i>() functions encounter such a file, they assume the file to be a shell script and invoke a known command interpreter
|
|
to interpret such files. This is now required by IEEE Std 1003.1-2001. These implementations of <i>execvp</i>() and
|
|
<i>execlp</i>() only give the [ENOEXEC] error in the rare case of a problem with the command interpreter's executable file. Because
|
|
of these implementations, the [ENOEXEC] error is not mentioned for <i>execlp</i>() or <i>execvp</i>(), although implementations can
|
|
still give it.</p>
|
|
|
|
<p>Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the
|
|
character string <tt>"#!"</tt> and using the remainder of the first line of the file as the name of the command interpreter to
|
|
execute.</p>
|
|
|
|
<p>One potential source of confusion noted by the standard developers is over how the contents of a process image file affect the
|
|
behavior of the <i>exec</i> family of functions. The following is a description of the actions taken:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>If the process image file is a valid executable (in a format that is executable and valid and having appropriate permission) for
|
|
this system, then the system executes the file.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>If the process image file has appropriate permission and is in a format that is executable but not valid for this system (such
|
|
as a recognized binary for another architecture), then this is an error and <i>errno</i> is set to [EINVAL] (see later RATIONALE on
|
|
[EINVAL]).</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>If the process image file has appropriate permission but is not otherwise recognized:</p>
|
|
|
|
<ol type="a">
|
|
<li>
|
|
<p>If this is a call to <i>execlp</i>() or <i>execvp</i>(), then they invoke a command interpreter assuming that the process image
|
|
file is a shell script.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>If this is not a call to <i>execlp</i>() or <i>execvp</i>(), then an error occurs and <i>errno</i> is set to [ENOEXEC].</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Applications that do not require to access their arguments may use the form:</p>
|
|
|
|
<pre>
|
|
<tt>main(void)
|
|
</tt>
|
|
</pre>
|
|
|
|
as specified in the ISO C standard. However, the implementation will always provide the two arguments <i>argc</i> and
|
|
<i>argv</i>, even if they are not used.
|
|
|
|
<p>Some implementations provide a third argument to <i>main</i>() called <i>envp</i>. This is defined as a pointer to the
|
|
environment. The ISO C standard specifies invoking <i>main</i>() with two arguments, so implementations must support
|
|
applications written this way. Since this volume of IEEE Std 1003.1-2001 defines the global variable <i>environ</i>,
|
|
which is also provided by historical implementations and can be used anywhere that <i>envp</i> could be used, there is no
|
|
functional need for the <i>envp</i> argument. Applications should use the <a href="../functions/getenv.html"><i>getenv</i>()</a>
|
|
function rather than accessing the environment directly via either <i>envp</i> or <i>environ</i>. Implementations are required to
|
|
support the two-argument calling sequence, but this does not prohibit an implementation from supporting <i>envp</i> as an optional
|
|
third argument.</p>
|
|
|
|
<p>This volume of IEEE Std 1003.1-2001 specifies that signals set to SIG_IGN remain set to SIG_IGN, and that the process
|
|
signal mask be unchanged across an <i>exec</i>. This is consistent with historical implementations, and it permits some useful
|
|
functionality, such as the <a href="../utilities/nohup.html"><i>nohup</i></a> command. However, it should be noted that many
|
|
existing applications wrongly assume that they start with certain signals set to the default action and/or unblocked. In
|
|
particular, applications written with a simpler signal model that does not include blocking of signals, such as the one in the
|
|
ISO C standard, may not behave properly if invoked with some signals blocked. Therefore, it is best not to block or ignore
|
|
signals across <i>exec</i>s without explicit reason to do so, and especially not to block signals across <i>exec</i>s of arbitrary
|
|
(not closely co-operating) programs.</p>
|
|
|
|
<p>The <i>exec</i> functions always save the value of the effective user ID and effective group ID of the process at the completion
|
|
of the <i>exec</i>, whether or not the set-user-ID or the set-group-ID bit of the process image file is set.</p>
|
|
|
|
<p>The statement about <i>argv</i>[] and <i>envp</i>[] being constants is included to make explicit to future writers of language
|
|
bindings that these objects are completely constant. Due to a limitation of the ISO C standard, it is not possible to state
|
|
that idea in standard C. Specifying two levels of <i>const</i>- <i>qualification</i> for the <i>argv</i>[] and <i>envp</i>[]
|
|
parameters for the <i>exec</i> functions may seem to be the natural choice, given that these functions do not modify either the
|
|
array of pointers or the characters to which the function points, but this would disallow existing correct code. Instead, only the
|
|
array of pointers is noted as constant. The table of assignment compatibility for <i>dst</i>= <i>src</i> derived from the
|
|
ISO C standard summarizes the compatibility:</p>
|
|
|
|
<center>
|
|
<table border="1" cellpadding="3" align="center">
|
|
<tr valign="top">
|
|
<th align="right">
|
|
<p class="tent"><i>dst</i>:</p>
|
|
</th>
|
|
<th align="left">
|
|
<p class="tent"><b>char *[]</b></p>
|
|
</th>
|
|
<th align="left">
|
|
<p class="tent"><b>const char *[]</b></p>
|
|
</th>
|
|
<th align="left">
|
|
<p class="tent"><b>char *const[]</b></p>
|
|
</th>
|
|
<th align="left">
|
|
<p class="tent"><b>const char *const[]</b></p>
|
|
</th>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b><i>src</i>:</b></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"> </p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"> </p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"> </p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent"> </p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>char *[]</b></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">VALID</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">VALID</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>const char *[]</b></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">VALID</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">VALID</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>char * const []</b></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">VALID</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr valign="top">
|
|
<td align="left">
|
|
<p class="tent"><b>const char *const[]</b></p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">-</p>
|
|
</td>
|
|
<td align="center">
|
|
<p class="tent">VALID</p>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</center>
|
|
|
|
<p>Since all existing code has a source type matching the first row, the column that gives the most valid combinations is the third
|
|
column. The only other possibility is the fourth column, but using it would require a cast on the <i>argv</i> or <i>envp</i>
|
|
arguments. It is unfortunate that the fourth column cannot be used, because the declaration a non-expert would naturally use would
|
|
be that in the second row.</p>
|
|
|
|
<p>The ISO C standard and this volume of IEEE Std 1003.1-2001 do not conflict on the use of <i>environ</i>, but some
|
|
historical implementations of <i>environ</i> may cause a conflict. As long as <i>environ</i> is treated in the same way as an entry
|
|
point (for example, <a href="../functions/fork.html"><i>fork</i>()</a>), it conforms to both standards. A library can contain <a
|
|
href="../functions/fork.html"><i>fork</i>()</a>, but if there is a user-provided <a href=
|
|
"../functions/fork.html"><i>fork</i>()</a>, that <a href="../functions/fork.html"><i>fork</i>()</a> is given precedence and no
|
|
problem ensues. The situation is similar for <i>environ</i>: the definition in this volume of IEEE Std 1003.1-2001 is to
|
|
be used if there is no user-provided <i>environ</i> to take precedence. At least three implementations are known to exist that
|
|
solve this problem.</p>
|
|
|
|
<dl compact>
|
|
<dt>[E2BIG]</dt>
|
|
|
|
<dd>The limit {ARG_MAX} applies not just to the size of the argument list, but to the sum of that and the size of the environment
|
|
list.</dd>
|
|
|
|
<dt>[EFAULT]</dt>
|
|
|
|
<dd>Some historical systems return [EFAULT] rather than [ENOEXEC] when the new process image file is corrupted. They are
|
|
non-conforming.</dd>
|
|
|
|
<dt>[EINVAL]</dt>
|
|
|
|
<dd>This error condition was added to IEEE Std 1003.1-2001 to allow an implementation to detect executable files
|
|
generated for different architectures, and indicate this situation to the application. Historical implementations of shells,
|
|
<i>execvp</i>(), and <i>execlp</i>() that encounter an [ENOEXEC] error will execute a shell on the assumption that the file is a
|
|
shell script. This will not produce the desired effect when the file is a valid executable for a different architecture. An
|
|
implementation may now choose to avoid this problem by returning [EINVAL] when a valid executable for a different architecture is
|
|
encountered. Some historical implementations return [EINVAL] to indicate that the <i>path</i> argument contains a character with
|
|
the high order bit set. The standard developers chose to deviate from historical practice for the following reasons:
|
|
|
|
<ol>
|
|
<li>
|
|
<p>The new utilization of [EINVAL] will provide some measure of utility to the user community.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Historical use of [EINVAL] is not acceptable in an internationalized operating environment.</p>
|
|
</li>
|
|
</ol>
|
|
</dd>
|
|
|
|
<dt>[ENAMETOOLONG]</dt>
|
|
|
|
<dd>
|
|
Since the file pathname may be constructed by taking elements in the <i>PATH</i> variable and putting them together with the
|
|
filename, the [ENAMETOOLONG] error condition could also be reached this way.</dd>
|
|
|
|
<dt>[ETXTBSY]</dt>
|
|
|
|
<dd>System V returns this error when the executable file is currently open for writing by some process. This volume of
|
|
IEEE Std 1003.1-2001 neither requires nor prohibits this behavior.</dd>
|
|
</dl>
|
|
|
|
<p>Other systems (such as System V) may return [EINTR] from <i>exec</i>. This is not addressed by this volume of
|
|
IEEE Std 1003.1-2001, but implementations may have a window between the call to <i>exec</i> and the time that a signal
|
|
could cause one of the <i>exec</i> calls to return with [EINTR].</p>
|
|
|
|
<p>An explicit statement regarding the floating-point environment (as defined in the <a href=
|
|
"../basedefs/fenv.h.html"><i><fenv.h></i></a> header) was added to make it clear that the floating-point environment is set
|
|
to its default when a call to one of the <i>exec</i> functions succeeds. The requirements for inheritance or setting to the default
|
|
for other process and thread start-up functions is covered by more generic statements in their descriptions and can be summarized
|
|
as follows:</p>
|
|
|
|
<dl compact>
|
|
<dt><i>posix_spawn</i>()</dt>
|
|
|
|
<dd>Set to default.</dd>
|
|
|
|
<dt><i>fork</i>()</dt>
|
|
|
|
<dd>Inherit.</dd>
|
|
|
|
<dt><i>pthread_create</i>()</dt>
|
|
|
|
<dd>Inherit.</dd>
|
|
</dl>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_09"></a>FUTURE DIRECTIONS</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_10"></a>SEE ALSO</h4>
|
|
|
|
<blockquote>
|
|
<p><a href="alarm.html"><i>alarm</i>()</a> , <a href="atexit.html"><i>atexit</i>()</a> , <a href="chmod.html"><i>chmod</i>()</a> ,
|
|
<a href="close.html"><i>close</i>()</a> , <a href="exit.html"><i>exit</i>()</a> , <a href="fcntl.html"><i>fcntl</i>()</a> , <a
|
|
href="fork.html"><i>fork</i>()</a> , <a href="fstatvfs.html"><i>fstatvfs</i>()</a> , <a href="getenv.html"><i>getenv</i>()</a> , <a
|
|
href="getitimer.html"><i>getitimer</i>()</a> , <a href="getrlimit.html"><i>getrlimit</i>()</a> , <a href=
|
|
"mmap.html"><i>mmap</i>()</a> , <a href="nice.html"><i>nice</i>()</a> , <a href="posix_spawn.html"><i>posix_spawn</i>()</a> , <a
|
|
href="posix_trace_eventid_open.html"><i>posix_trace_eventid_open</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="putenv.html"><i>putenv</i>()</a> , <a
|
|
href="semop.html"><i>semop</i>()</a> , <a href="setlocale.html"><i>setlocale</i>()</a> , <a href="shmat.html"><i>shmat</i>()</a> ,
|
|
<a href="sigaction.html"><i>sigaction</i>()</a> , <a href="sigaltstack.html"><i>sigaltstack</i>()</a> , <a href=
|
|
"sigpending.html"><i>sigpending</i>()</a> , <a href="sigprocmask.html"><i>sigprocmask</i>()</a> , <a href=
|
|
"system.html"><i>system</i>()</a> , <a href="times.html"><i>times</i>()</a> , <a href="ulimit.html"><i>ulimit</i>()</a> , <a href=
|
|
"umask.html"><i>umask</i>()</a> , the Base Definitions volume of IEEE Std 1003.1-2001, <a href=
|
|
"../basedefs/xbd_chap11.html#tag_11">Chapter 11, General Terminal Interface</a>, <a href=
|
|
"../basedefs/unistd.h.html"><i><unistd.h></i></a></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_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_130_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>Large File Summit extensions are added.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_130_13"></a>Issue 6</h4>
|
|
|
|
<blockquote>
|
|
<p>The following new requirements on POSIX implementations derive from alignment with the Single UNIX Specification:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>In the DESCRIPTION, behavior is defined for when the process image file is not a valid executable.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>In this issue, _POSIX_SAVED_IDS is mandated, thus the effective user ID and effective group ID of the new process image shall be
|
|
saved (as the saved set-user-ID and the saved set-group-ID) for use by the <a href="../functions/setuid.html"><i>setuid</i>()</a>
|
|
function.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The [ELOOP] mandatory error condition is added.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A second [ENAMETOOLONG] is added as an optional error condition.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The [ETXTBSY] optional error condition is added.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The following changes were made to align with the IEEE P1003.1a draft standard:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>The [EINVAL] mandatory error condition is added.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The [ELOOP] optional error condition is added.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The description of CPU-time clock semantics is added for alignment with IEEE Std 1003.1d-1999.</p>
|
|
|
|
<p>The DESCRIPTION is updated for alignment with IEEE Std 1003.1j-2000 by adding semantics for typed memory.</p>
|
|
|
|
<p>The DESCRIPTION is updated to avoid use of the term "must" for application requirements.</p>
|
|
|
|
<p>The description of tracing semantics is added for alignment with IEEE Std 1003.1q-2000.</p>
|
|
|
|
<p>IEEE PASC Interpretation 1003.1 #132 is applied.</p>
|
|
|
|
<p>The DESCRIPTION is updated to make it explicit that the floating-point environment in the new process image is set to the
|
|
default.</p>
|
|
|
|
<p>The DESCRIPTION and RATIONALE are updated to include clarifications of how the contents of a process image file affect the
|
|
behavior of the <i>exec</i> functions.</p>
|
|
</blockquote>
|
|
|
|
<div class="box"><em>End of informative text.</em></div>
|
|
|
|
<hr>
|
|
<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>
|
|
|