1EXEC(P)                    POSIX Programmer's Manual                   EXEC(P)
2
3
4

NAME

6       environ, execl, execv, execle, execve, execlp, execvp - execute a file
7

SYNOPSIS

9       #include <unistd.h>
10
11       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
20

DESCRIPTION

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
28       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
31
32              int main (int argc, char *argv[]);
33
34       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
38
39              extern char **environ;
40
41       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
46       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
52       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
56       The  argument path points to a pathname that identifies the new process
57       image file.
58
59       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
68       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
77
78              execl(<shell path>, arg0, file, arg1, ..., (char *)0);
79
80       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
85       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
91       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
98       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
102       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
106       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
111       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
119       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
126       Directory streams open in the calling process image shall be closed  in
127       the new process image.
128
129       The  state  of  the floating-point environment in the new process image
130       shall be set to the default.
131
132       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
136
137              setlocale(LC_ALL, "C")
138
139       shall be executed at start-up.
140
141       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
153       After a successful call to any of the  exec  functions,  any  functions
154       previously registered by atexit() are no longer registered.
155
156       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
171       Any shared memory segments attached to the calling process image  shall
172       not be attached to the new process image.
173
174       Any  named semaphores open in the calling process shall be closed as if
175       by appropriate calls to sem_close().
176
177       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
180       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
188       Memory  mappings created in the process are unmapped before the address
189       space is rebuilt for the new process image.
190
191       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
196       Per-process  timers  created  by  the  calling process shall be deleted
197       before replacing the current process image with the new process image.
198
199       All open message queue descriptors in  the  calling  process  shall  be
200       closed, as described in mq_close() .
201
202       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
212       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
218       The  initial  value  of the CPU-time clock of the initial thread of the
219       new process image shall be set to zero.
220
221       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
228       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
232       The  new  process  shall inherit at least the following attributes from
233       the calling process image:
234
235        * Nice value (see nice() )
236
237        * semadj values (see semop() )
238
239        * Process ID
240
241        * Parent process ID
242
243        * Process group ID
244
245        * Session membership
246
247        * Real user ID
248
249        * Real group ID
250
251        * Supplementary group IDs
252
253        * Time left until an alarm clock signal (see alarm() )
254
255        * Current working directory
256
257        * Root directory
258
259        * File mode creation mask (see umask() )
260
261        * File size limit (see ulimit() )
262
263        * Process signal mask (see sigprocmask() )
264
265        * Pending signal (see sigpending() )
266
267        * tms_utime, tms_stime, tms_cutime, and tms_cstime (see times() )
268
269        * Resource limits
270
271        * Controlling terminal
272
273        * Interval timers
274
275       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
280       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
285       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
298       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

RETURN VALUE

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

ERRORS

307       The exec functions shall fail if:
308
309       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
313       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
319       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
323       ELOOP  A loop exists in symbolic links encountered during resolution of
324              the path or file argument.
325
326       ENAMETOOLONG
327              The length of the path or file arguments exceeds {PATH_MAX} or a
328              pathname component is longer than {NAME_MAX}.
329
330       ENOENT A component of path or file does not name an  existing  file  or
331              path or file is an empty string.
332
333       ENOTDIR
334              A component of the new process image file's path prefix is not a
335              directory.
336
337
338       The exec functions, except for execlp() and execvp(), shall fail if:
339
340       ENOEXEC
341              The new process image file has the appropriate access permission
342              but has an unrecognized format.
343
344
345       The exec functions may fail if:
346
347       ELOOP  More  than  {SYMLOOP_MAX} symbolic links were encountered during
348              resolution of the path or file argument.
349
350       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
355       ENOMEM The new process image requires more memory than  is  allowed  by
356              the hardware or system-imposed memory management constraints.
357
358       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
362
363       The following sections are informative.
364

EXAMPLES

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
371
372              #include <unistd.h>
373
374
375              int ret;
376              ...
377              ret = execl ("/bin/ls", "ls", "-1", (char *)0);
378
379   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
384
385              #include <unistd.h>
386
387
388              int ret;
389              char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
390              ...
391              ret = execle ("/bin/ls", "ls", "-l", (char *)0, env);
392
393   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
397
398              #include <unistd.h>
399
400
401              int ret;
402              ...
403              ret = execlp ("ls", "ls", "-l", (char *)0);
404
405   Using execv()
406       The  following  example  passes  arguments to the ls command in the cmd
407       array.
408
409
410              #include <unistd.h>
411
412
413              int ret;
414              char *cmd[] = { "ls", "-l", (char *)0 };
415              ...
416              ret = execv ("/bin/ls", cmd);
417
418   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
423
424              #include <unistd.h>
425
426
427              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
433   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
438
439              #include <unistd.h>
440
441
442              int ret;
443              char *cmd[] = { "ls", "-l", (char *)0 };
444              ...
445              ret = execvp ("ls", cmd);
446

APPLICATION USAGE

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
453       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
457       The environ array should not be accessed directly by the application.
458
459       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

RATIONALE

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
477       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
488       Historically  there  have  been  two ways that implementations can exec
489       shell scripts.
490
491       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
503       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
508       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
513        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
517        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
522        3. If  the  process  image  file has appropriate permission but is not
523           otherwise recognized:
524
525            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
529            b. If this is not a call to execlp() or execvp(),  then  an  error
530               occurs and errno is set to [ENOEXEC].
531
532       Applications  that do not require to access their arguments may use the
533       form:
534
535
536              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
541       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
554       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
568       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
573       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
585    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
592       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
599       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
610       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
614       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
618       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
633               1. The new utilization of [EINVAL] will provide some measure of
634                  utility to the user community.
635
636               2. Historical use of [EINVAL] is not acceptable in an  interna‐
637                  tionalized operating environment.
638
639       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
645       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
651
652       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
657       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
665       posix_spawn()
666              Set to default.
667
668       fork() Inherit.
669
670       pthread_create()
671              Inherit.
672
673

FUTURE DIRECTIONS

675       None.
676

SEE ALSO

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 .
697
698
699
700IEEE/The Open Group                  2003                              EXEC(P)
Impressum