1EXEC(3P) POSIX Programmer's Manual EXEC(3P)
2
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 environ, execl, execv, execle, execve, execlp, execvp - execute a file
13
15 #include <unistd.h>
16 extern char **environ;
18 int execl(const char *path, const char *arg0, ... /*, (char *)0 */);
19 int execv(const char *path, char *const argv[]);
20 int execle(const char *path, const char *arg0, ... /*,
21 (char *)0, char *const envp[]*/);
22 int execve(const char *path, char *const argv[], char *const envp[]);
23 int execlp(const char *file, const char *arg0, ... /*, (char *)0 */);
24 int execvp(const char *file, char *const argv[]);
25
28 The exec family of functions shall replace the current process image
29 with a new process image. The new image shall be constructed from a
30 regular, executable file called the new process image file. There shall
31 be no return from a successful exec, because the calling process image
32 is overlaid by the new process image.
33 When a C-language program is executed as a result of this call, it
35 shall be entered as a C-language function call as follows:
36 int main (int argc, char *argv[]);
39 where argc is the argument count and argv is an array of character
41 pointers to the arguments themselves. In addition, the following vari‐
42 able:
43 extern char **environ;
46 is initialized as a pointer to an array of character pointers to the
48 environment strings. The argv and environ arrays are each terminated by
49 a null pointer. The null pointer terminating the argv array is not
50 counted in argc.
51 Conforming multi-threaded applications shall not use the environ vari‐
53 able to access or modify any environment variable while any other
54 thread is concurrently modifying any environment variable. A call to
55 any function dependent on any environment variable shall be considered
56 a use of the environ variable to access that environment variable.
57 The arguments specified by a program with one of the exec functions
59 shall be passed on to the new process image in the corresponding main()
60 arguments.
61 The argument path points to a pathname that identifies the new process
63 image file.
64 The argument file is used to construct a pathname that identifies the
66 new process image file. If the file argument contains a slash charac‐
67 ter, the file argument shall be used as the pathname for this file.
68 Otherwise, the path prefix for this file is obtained by a search of the
69 directories passed as the environment variable PATH (see the Base Defi‐
70 nitions volume of IEEE Std 1003.1-2001, Chapter 8, Environment Vari‐
71 ables). If this environment variable is not present, the results of
72 the search are implementation-defined.
73 There are two distinct ways in which the contents of the process image
75 file may cause the execution to fail, distinguished by the setting of
76 errno to either [ENOEXEC] or [EINVAL] (see the ERRORS section). In the
77 cases where the other members of the exec family of functions would
78 fail and set errno to [ENOEXEC], the execlp() and execvp() functions
79 shall execute a command interpreter and the environment of the executed
80 command shall be as if the process invoked the sh utility using execl()
81 as follows:
82 execl(<shell path>, arg0, file, arg1, ..., (char *)0);
85 where <shell path> is an unspecified pathname for the sh utility, file
87 is the process image file, and for execvp(), where arg0, arg1, and so
88 on correspond to the values passed to execvp() in argv[0], argv[1], and
89 so on.
90 The arguments represented by arg0,... are pointers to null-terminated
92 character strings. These strings shall constitute the argument list
93 available to the new process image. The list is terminated by a null
94 pointer. The argument arg0 should point to a filename that is associ‐
95 ated with the process being started by one of the exec functions.
96 The argument argv is an array of character pointers to null-terminated
98 strings. The application shall ensure that the last member of this
99 array is a null pointer. These strings shall constitute the argument
100 list available to the new process image. The value in argv[0] should
101 point to a filename that is associated with the process being started
102 by one of the exec functions.
103 The argument envp is an array of character pointers to null-terminated
105 strings. These strings shall constitute the environment for the new
106 process image. The envp array is terminated by a null pointer.
107 For those forms not containing an envp pointer ( execl(), execv(), exe‐
109 clp(), and execvp()), the environment for the new process image shall
110 be taken from the external variable environ in the calling process.
111 The number of bytes available for the new process' combined argument
113 and environment lists is {ARG_MAX}. It is implementation-defined
114 whether null terminators, pointers, and/or any alignment bytes are
115 included in this total.
116 File descriptors open in the calling process image shall remain open in
118 the new process image, except for those whose close-on- exec flag
119 FD_CLOEXEC is set. For those file descriptors that remain open, all
120 attributes of the open file description remain unchanged. For any file
121 descriptor that is closed for this reason, file locks are removed as a
122 result of the close as described in close(). Locks that are not removed
123 by closing of file descriptors remain unchanged.
124 If file descriptors 0, 1, and 2 would otherwise be closed after a suc‐
126 cessful call to one of the exec family of functions, and the new
127 process image file has the set-user-ID or set-group-ID file mode bits
128 set, and the ST_NOSUID bit is not set for the file system containing
129 the new process image file, implementations may open an unspecified
130 file for each of these file descriptors in the new process image.
131 Directory streams open in the calling process image shall be closed in
133 the new process image.
134 The state of the floating-point environment in the new process image
136 shall be set to the default.
137 The state of conversion descriptors and message catalog descriptors in
139 the new process image is undefined. For the new process image, the
140 equivalent of:
141 setlocale(LC_ALL, "C")
144 shall be executed at start-up.
146 Signals set to the default action (SIG_DFL) in the calling process
148 image shall be set to the default action in the new process image.
149 Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling
150 process image shall be set to be ignored by the new process image. Sig‐
151 nals set to be caught by the calling process image shall be set to the
152 default action in the new process image (see <signal.h>). If the
153 SIGCHLD signal is set to be ignored by the calling process image, it is
154 unspecified whether the SIGCHLD signal is set to be ignored or to the
155 default action in the new process image. After a successful call to
156 any of the exec functions, alternate signal stacks are not preserved
157 and the SA_ONSTACK flag shall be cleared for all signals.
158 After a successful call to any of the exec functions, any functions
160 previously registered by atexit() are no longer registered.
161 If the ST_NOSUID bit is set for the file system containing the new
163 process image file, then the effective user ID, effective group ID,
164 saved set-user-ID, and saved set-group-ID are unchanged in the new
165 process image. Otherwise, if the set-user-ID mode bit of the new
166 process image file is set, the effective user ID of the new process
167 image shall be set to the user ID of the new process image file. Simi‐
168 larly, if the set-group-ID mode bit of the new process image file is
169 set, the effective group ID of the new process image shall be set to
170 the group ID of the new process image file. The real user ID, real
171 group ID, and supplementary group IDs of the new process image shall
172 remain the same as those of the calling process image. The effective
173 user ID and effective group ID of the new process image shall be saved
174 (as the saved set-user-ID and the saved set-group-ID) for use by
175 setuid().
176 Any shared memory segments attached to the calling process image shall
178 not be attached to the new process image.
179 Any named semaphores open in the calling process shall be closed as if
181 by appropriate calls to sem_close().
182 Any blocks of typed memory that were mapped in the calling process are
184 unmapped, as if munmap() was implicitly called to unmap them.
185 Memory locks established by the calling process via calls to mlockall()
187 or mlock() shall be removed. If locked pages in the address space of
188 the calling process are also mapped into the address spaces of other
189 processes and are locked by those processes, the locks established by
190 the other processes shall be unaffected by the call by this process to
191 the exec function. If the exec function fails, the effect on memory
192 locks is unspecified.
193 Memory mappings created in the process are unmapped before the address
195 space is rebuilt for the new process image.
196 For the SCHED_FIFO and SCHED_RR scheduling policies, the policy and
198 priority settings shall not be changed by a call to an exec function.
199 For other scheduling policies, the policy and priority settings on exec
200 are implementation-defined.
201 Per-process timers created by the calling process shall be deleted
203 before replacing the current process image with the new process image.
204 All open message queue descriptors in the calling process shall be
206 closed, as described in mq_close().
207 Any outstanding asynchronous I/O operations may be canceled. Those
209 asynchronous I/O operations that are not canceled shall complete as if
210 the exec function had not yet occurred, but any associated signal noti‐
211 fications shall be suppressed. It is unspecified whether the exec func‐
212 tion itself blocks awaiting such I/O completion. In no event, however,
213 shall the new process image created by the exec function be affected by
214 the presence of outstanding asynchronous I/O operations at the time the
215 exec function is called. Whether any I/O is canceled, and which I/O may
216 be canceled upon exec, is implementation-defined.
217 The new process image shall inherit the CPU-time clock of the calling
219 process image. This inheritance means that the process CPU-time clock
220 of the process being exec-ed shall not be reinitialized or altered as a
221 result of the exec function other than to reflect the time spent by the
222 process executing the exec function itself.
223 The initial value of the CPU-time clock of the initial thread of the
225 new process image shall be set to zero.
226 If the calling process is being traced, the new process image shall
228 continue to be traced into the same trace stream as the original
229 process image, but the new process image shall not inherit the mapping
230 of trace event names to trace event type identifiers that was defined
231 by calls to the posix_trace_eventid_open() or the
232 posix_trace_trid_eventid_open() functions in the calling process image.
233 If the calling process is a trace controller process, any trace streams
235 that were created by the calling process shall be shut down as
236 described in the posix_trace_shutdown() function.
237 The new process shall inherit at least the following attributes from
239 the calling process image:
240 * Nice value (see nice())
242 * semadj values (see semop())
244 * Process ID
246 * Parent process ID
248 * Process group ID
250 * Session membership
252 * Real user ID
254 * Real group ID
256 * Supplementary group IDs
258 * Time left until an alarm clock signal (see alarm())
260 * Current working directory
262 * Root directory
264 * File mode creation mask (see umask())
266 * File size limit (see ulimit())
268 * Process signal mask (see sigprocmask())
270 * Pending signal (see sigpending())
272 * tms_utime, tms_stime, tms_cutime, and tms_cstime (see times())
274 * Resource limits
276 * Controlling terminal
278 * Interval timers
280 All other process attributes defined in this volume of
282 IEEE Std 1003.1-2001 shall be the same in the new and old process
283 images. The inheritance of process attributes not defined by this vol‐
284 ume of IEEE Std 1003.1-2001 is implementation-defined.
285 A call to any exec function from a process with more than one thread
287 shall result in all threads being terminated and the new executable
288 image being loaded and executed. No destructor functions shall be
289 called.
290 Upon successful completion, the exec functions shall mark for update
292 the st_atime field of the file. If an exec function failed but was able
293 to locate the process image file, whether the st_atime field is marked
294 for update is unspecified. Should the exec function succeed, the
295 process image file shall be considered to have been opened with open().
296 The corresponding close() shall be considered to occur at a time after
297 this open, but before process termination or successful completion of a
298 subsequent call to one of the exec functions, posix_spawn(), or
299 posix_spawnp(). The argv[] and envp[] arrays of pointers and the
300 strings to which those arrays point shall not be modified by a call to
301 one of the exec functions, except as a consequence of replacing the
302 process image.
303 The saved resource limits in the new process image are set to be a copy
305 of the process' corresponding hard and soft limits.
306
308 If one of the exec functions returns to the calling process image, an
309 error has occurred; the return value shall be -1, and errno shall be
310 set to indicate the error.
311
313 The exec functions shall fail if:
314 E2BIG The number of bytes used by the new process image's argument
316 list and environment list is greater than the system-imposed
317 limit of {ARG_MAX} bytes.
318 EACCES Search permission is denied for a directory listed in the new
320 process image file's path prefix, or the new process image file
321 denies execution permission, or the new process image file is
322 not a regular file and the implementation does not support exe‐
323 cution of files of its type.
324 EINVAL The new process image file has the appropriate permission and
326 has a recognized executable binary format, but the system does
327 not support execution of a file with this format.
328 ELOOP A loop exists in symbolic links encountered during resolution of
330 the path or file argument.
331 ENAMETOOLONG
333 The length of the path or file arguments exceeds {PATH_MAX} or a
334 pathname component is longer than {NAME_MAX}.
335 ENOENT A component of path or file does not name an existing file or
337 path or file is an empty string.
338 ENOTDIR
340 A component of the new process image file's path prefix is not a
341 directory.
342 The exec functions, except for execlp() and execvp(), shall fail if:
345 ENOEXEC
347 The new process image file has the appropriate access permission
348 but has an unrecognized format.
349 The exec functions may fail if:
352 ELOOP More than {SYMLOOP_MAX} symbolic links were encountered during
354 resolution of the path or file argument.
355 ENAMETOOLONG
357 As a result of encountering a symbolic link in resolution of the
358 path argument, the length of the substituted pathname string
359 exceeded {PATH_MAX}.
360 ENOMEM The new process image requires more memory than is allowed by
362 the hardware or system-imposed memory management constraints.
363 ETXTBSY
365 The new process image file is a pure procedure (shared text)
366 file that is currently open for writing by some process.
367 The following sections are informative.
370
372 Using execl()
373 The following example executes the ls command, specifying the pathname
374 of the executable ( /bin/ls) and using arguments supplied directly to
375 the command to produce single-column output.
376 #include <unistd.h>
379 int ret;
382 ...
383 ret = execl ("/bin/ls", "ls", "-1", (char *)0);
384 Using execle()
386 The following example is similar to Using execl() . In addition, it
387 specifies the environment for the new process image using the env argu‐
388 ment.
389 #include <unistd.h>
392 int ret;
395 char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
396 ...
397 ret = execle ("/bin/ls", "ls", "-l", (char *)0, env);
398 Using execlp()
400 The following example searches for the location of the ls command among
401 the directories specified by the PATH environment variable.
402 #include <unistd.h>
405 int ret;
408 ...
409 ret = execlp ("ls", "ls", "-l", (char *)0);
410 Using execv()
412 The following example passes arguments to the ls command in the cmd
413 array.
414 #include <unistd.h>
417 int ret;
420 char *cmd[] = { "ls", "-l", (char *)0 };
421 ...
422 ret = execv ("/bin/ls", cmd);
423 Using execve()
425 The following example passes arguments to the ls command in the cmd
426 array, and specifies the environment for the new process image using
427 the env argument.
428 #include <unistd.h>
431 int ret;
434 char *cmd[] = { "ls", "-l", (char *)0 };
435 char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
436 ...
437 ret = execve ("/bin/ls", cmd, env);
438 Using execvp()
440 The following example searches for the location of the ls command among
441 the directories specified by the PATH environment variable, and passes
442 arguments to the ls command in the cmd array.
443 #include <unistd.h>
446 int ret;
449 char *cmd[] = { "ls", "-l", (char *)0 };
450 ...
451 ret = execvp ("ls", cmd);
452
454 As the state of conversion descriptors and message catalog descriptors
455 in the new process image is undefined, conforming applications should
456 not rely on their use and should close them prior to calling one of the
457 exec functions.
458 Applications that require other than the default POSIX locale should
460 call setlocale() with the appropriate parameters to establish the
461 locale of the new process.
462 The environ array should not be accessed directly by the application.
464 Applications should not depend on file descriptors 0, 1, and 2 being
466 closed after an exec. A future version may allow these file descriptors
467 to be automatically opened for any process.
468
470 Early proposals required that the value of argc passed to main() be
471 "one or greater". This was driven by the same requirement in drafts of
472 the ISO C standard. In fact, historical implementations have passed a
473 value of zero when no arguments are supplied to the caller of the exec
474 functions. This requirement was removed from the ISO C standard and
475 subsequently removed from this volume of IEEE Std 1003.1-2001 as well.
476 The wording, in particular the use of the word should, requires a
477 Strictly Conforming POSIX Application to pass at least one argument to
478 the exec function, thus guaranteeing that argc be one or greater when
479 invoked by such an application. In fact, this is good practice, since
480 many existing applications reference argv[0] without first checking the
481 value of argc.
482 The requirement on a Strictly Conforming POSIX Application also states
484 that the value passed as the first argument be a filename associated
485 with the process being started. Although some existing applications
486 pass a pathname rather than a filename in some circumstances, a file‐
487 name is more generally useful, since the common usage of argv[0] is in
488 printing diagnostics. In some cases the filename passed is not the
489 actual filename of the file; for example, many implementations of the
490 login utility use a convention of prefixing a hyphen ( '-' ) to the
491 actual filename, which indicates to the command interpreter being
492 invoked that it is a "login shell".
493 Historically there have been two ways that implementations can exec
495 shell scripts.
496 One common historical implementation is that the execl(), execv(), exe‐
498 cle(), and execve() functions return an [ENOEXEC] error for any file
499 not recognizable as executable, including a shell script. When the exe‐
500 clp() and execvp() functions encounter such a file, they assume the
501 file to be a shell script and invoke a known command interpreter to
502 interpret such files. This is now required by IEEE Std 1003.1-2001.
503 These implementations of execvp() and execlp() only give the [ENOEXEC]
504 error in the rare case of a problem with the command interpreter's exe‐
505 cutable file. Because of these implementations, the [ENOEXEC] error is
506 not mentioned for execlp() or execvp(), although implementations can
507 still give it.
508 Another way that some historical implementations handle shell scripts
510 is by recognizing the first two bytes of the file as the character
511 string "#!" and using the remainder of the first line of the file as
512 the name of the command interpreter to execute.
513 One potential source of confusion noted by the standard developers is
515 over how the contents of a process image file affect the behavior of
516 the exec family of functions. The following is a description of the
517 actions taken:
518 1. If the process image file is a valid executable (in a format that
520 is executable and valid and having appropriate permission) for this
521 system, then the system executes the file.
522 2. If the process image file has appropriate permission and is in a
524 format that is executable but not valid for this system (such as a
525 recognized binary for another architecture), then this is an error
526 and errno is set to [EINVAL] (see later RATIONALE on [EINVAL]).
527 3. If the process image file has appropriate permission but is not
529 otherwise recognized:
530 a. If this is a call to execlp() or execvp(), then they invoke a
532 command interpreter assuming that the process image file is a
533 shell script.
534 b. If this is not a call to execlp() or execvp(), then an error
536 occurs and errno is set to [ENOEXEC].
537 Applications that do not require to access their arguments may use the
539 form:
540 main(void)
543 as specified in the ISO C standard. However, the implementation will
544 always provide the two arguments argc and argv, even if they are not
545 used.
546 Some implementations provide a third argument to main() called envp.
548 This is defined as a pointer to the environment. The ISO C standard
549 specifies invoking main() with two arguments, so implementations must
550 support applications written this way. Since this volume of
551 IEEE Std 1003.1-2001 defines the global variable environ, which is also
552 provided by historical implementations and can be used anywhere that
553 envp could be used, there is no functional need for the envp argument.
554 Applications should use the getenv() function rather than accessing the
555 environment directly via either envp or environ. Implementations are
556 required to support the two-argument calling sequence, but this does
557 not prohibit an implementation from supporting envp as an optional
558 third argument.
559 This volume of IEEE Std 1003.1-2001 specifies that signals set to
561 SIG_IGN remain set to SIG_IGN, and that the process signal mask be
562 unchanged across an exec. This is consistent with historical implemen‐
563 tations, and it permits some useful functionality, such as the nohup
564 command. However, it should be noted that many existing applications
565 wrongly assume that they start with certain signals set to the default
566 action and/or unblocked. In particular, applications written with a
567 simpler signal model that does not include blocking of signals, such as
568 the one in the ISO C standard, may not behave properly if invoked with
569 some signals blocked. Therefore, it is best not to block or ignore sig‐
570 nals across execs without explicit reason to do so, and especially not
571 to block signals across execs of arbitrary (not closely co-operating)
572 programs.
573 The exec functions always save the value of the effective user ID and
575 effective group ID of the process at the completion of the exec,
576 whether or not the set-user-ID or the set-group-ID bit of the process
577 image file is set.
578 The statement about argv[] and envp[] being constants is included to
580 make explicit to future writers of language bindings that these objects
581 are completely constant. Due to a limitation of the ISO C standard, it
582 is not possible to state that idea in standard C. Specifying two levels
583 of const- qualification for the argv[] and envp[] parameters for the
584 exec functions may seem to be the natural choice, given that these
585 functions do not modify either the array of pointers or the characters
586 to which the function points, but this would disallow existing correct
587 code. Instead, only the array of pointers is noted as constant. The ta‐
588 ble of assignment compatibility for dst= src derived from the ISO C
589 standard summarizes the compatibility:
590 dst: char *[] const char *[] char *const[] const char *const[]
592 src:
593 char *[] VALID - VALID -
594 const char *[] - VALID - VALID
595 char * const [] - - VALID -
596 const char *const[] - - - VALID
598 Since all existing code has a source type matching the first row, the
600 column that gives the most valid combinations is the third column. The
601 only other possibility is the fourth column, but using it would require
602 a cast on the argv or envp arguments. It is unfortunate that the fourth
603 column cannot be used, because the declaration a non-expert would natu‐
604 rally use would be that in the second row.
605 The ISO C standard and this volume of IEEE Std 1003.1-2001 do not con‐
607 flict on the use of environ, but some historical implementations of
608 environ may cause a conflict. As long as environ is treated in the
609 same way as an entry point (for example, fork()), it conforms to both
610 standards. A library can contain fork(), but if there is a user-pro‐
611 vided fork(), that fork() is given precedence and no problem ensues.
612 The situation is similar for environ: the definition in this volume of
613 IEEE Std 1003.1-2001 is to be used if there is no user-provided environ
614 to take precedence. At least three implementations are known to exist
615 that solve this problem.
616 E2BIG The limit {ARG_MAX} applies not just to the size of the argument
618 list, but to the sum of that and the size of the environment
619 list.
620 EFAULT Some historical systems return [EFAULT] rather than [ENOEXEC]
622 when the new process image file is corrupted. They are non-con‐
623 forming.
624 EINVAL This error condition was added to IEEE Std 1003.1-2001 to allow
626 an implementation to detect executable files generated for dif‐
627 ferent architectures, and indicate this situation to the appli‐
628 cation. Historical implementations of shells, execvp(), and exe‐
629 clp() that encounter an [ENOEXEC] error will execute a shell on
630 the assumption that the file is a shell script. This will not
631 produce the desired effect when the file is a valid executable
632 for a different architecture. An implementation may now choose
633 to avoid this problem by returning [EINVAL] when a valid exe‐
634 cutable for a different architecture is encountered. Some his‐
635 torical implementations return [EINVAL] to indicate that the
636 path argument contains a character with the high order bit set.
637 The standard developers chose to deviate from historical prac‐
638 tice for the following reasons:
639 1. The new utilization of [EINVAL] will provide some measure of
641 utility to the user community.
642 2. Historical use of [EINVAL] is not acceptable in an interna‐
644 tionalized operating environment.
645 ENAMETOOLONG
647 Since the file pathname may be constructed by taking elements in
648 the PATH variable and putting them together with the filename,
649 the [ENAMETOOLONG] error condition could also be reached this
650 way.
651 ETXTBSY
653 System V returns this error when the executable file is cur‐
654 rently open for writing by some process. This volume of
655 IEEE Std 1003.1-2001 neither requires nor prohibits this behav‐
656 ior.
657 Other systems (such as System V) may return [EINTR] from exec. This is
660 not addressed by this volume of IEEE Std 1003.1-2001, but implementa‐
661 tions may have a window between the call to exec and the time that a
662 signal could cause one of the exec calls to return with [EINTR].
663 An explicit statement regarding the floating-point environment (as
665 defined in the <fenv.h> header) was added to make it clear that the
666 floating-point environment is set to its default when a call to one of
667 the exec functions succeeds. The requirements for inheritance or set‐
668 ting to the default for other process and thread start-up functions is
669 covered by more generic statements in their descriptions and can be
670 summarized as follows:
671 posix_spawn()
673 Set to default.
674 fork() Inherit.
676 pthread_create()
678 Inherit.
679
682 None.
683
685 alarm(), atexit(), chmod(), close(), exit(), fcntl(), fork(),
686 fstatvfs(), getenv(), getitimer(), getrlimit(), mmap(), nice(),
687 posix_spawn(), posix_trace_eventid_open(), posix_trace_shutdown(),
688 posix_trace_trid_eventid_open(), putenv(), semop(), setlocale(),
689 shmat() , sigaction(), sigaltstack(), sigpending(), sigprocmask(), sys‐
690 tem(), times(), ulimit(), umask(), the Base Definitions volume of
691 IEEE Std 1003.1-2001, Chapter 11, General Terminal Interface,
692 <unistd.h>
693
695 Portions of this text are reprinted and reproduced in electronic form
696 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
697 -- Portable Operating System Interface (POSIX), The Open Group Base
698 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
699 Electrical and Electronics Engineers, Inc and The Open Group. In the
700 event of any discrepancy between this version and the original IEEE and
701 The Open Group Standard, the original IEEE and The Open Group Standard
702 is the referee document. The original Standard can be obtained online
703 at http://www.opengroup.org/unix/online.html .
704IEEE/The Open Group 2003 EXEC(3P)