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