# exec

## PROLOG



           This manual page is part of the POSIX Programmer's Manual.  The
           Linux implementation of this interface may differ (consult the
           corresponding Linux manual page for details of Linux behavior), or
           the interface may not be implemented on Linux.
    


## NAME



           environ, execl, execle, execlp, execv, execve, execvp, fexecve —
           execute a file
    


## SYNOPSIS



           #include <unistd.h>
    
           extern char **environ;
           int execl(const char *_path_ , const char *_arg0_ , ... /*, (char *)0 */);
           int execle(const char *_path_ , const char *_arg0_ , ... /*,
               (char *)0, char *const _envp_[]*/);
           int execlp(const char *_file_ , const char *_arg0_ , ... /*, (char *)0 */);
           int execv(const char *_path_ , char *const _argv_[]);
           int execve(const char *_path_ , char *const _argv_[], char *const _envp_[]);
           int execvp(const char *_file_ , char *const _argv_[]);
           int fexecve(int _fd_ , char *const _argv_[], char *const _envp_[]);
    


## DESCRIPTION



           The _exec_ family of functions shall replace the current process
           image with a new process image. The new image shall be constructed
           from a regular, executable file called the _new process image file_.
           There shall be no return from a successful _exec_ , because the
           calling process image is overlaid by the new process image.
    
           The _fexecve_() function shall be equivalent to the _execve_()
           function except that the file to be executed is determined by the
           file descriptor _fd_ instead of a pathname. The file offset of _fd_ is
           ignored.
    
           When a C-language program is executed as a result of a call to one
           of the _exec_ family of functions, it shall be entered as a C-
           language function call as follows:
    
               int main (_int argc, char *argv_[]);
    
           where _argc_ is the argument count and _argv_ is an array of character
           pointers to the arguments themselves.  In addition, the following
           variable, which must be declared by the user if it is to be used
           directly:
    
               extern char **environ;
    
           is initialized as a pointer to an array of character pointers to
           the environment strings. The _argv_ and _environ_ arrays are each
           terminated by a null pointer. The null pointer terminating the
           _argv_ array is not counted in _argc_.
    
           Applications can change the entire environment in a single
           operation by assigning the _environ_ variable to point to an array
           of character pointers to the new environment strings. After
           assigning a new value to _environ_ , applications should not rely on
           the new environment strings remaining part of the environment, as
           a call to _getenv_(), _putenv_(), _setenv_(), _unsetenv_(), or any
           function that is dependent on an environment variable may, on
           noticing that _environ_ has changed, copy the environment strings to
           a new array and assign _environ_ to point to it.
    
           Any application that directly modifies the pointers to which the
           _environ_ variable points has undefined behavior.
    
           Conforming multi-threaded applications shall not use the _environ_
           variable to access or modify any environment variable while any
           other thread is concurrently modifying any environment variable. A
           call to any function dependent on any environment variable shall
           be considered a use of the _environ_ variable to access that
           environment variable.
    
           The arguments specified by a program with one of the _exec_
           functions shall be passed on to the new process image in the
           corresponding _main_() arguments.
    
           The argument _path_ points to a pathname that identifies the new
           process image file.
    
           The argument _file_ is used to construct a pathname that identifies
           the new process image file. If the _file_ argument contains a
           <slash> character, the _file_ argument shall be used as the pathname
           for this file. Otherwise, the path prefix for this file is
           obtained by a search of the directories passed as the environment
           variable _PATH_ (see the Base Definitions volume of POSIX.1‐2017,
           _Chapter 8_ , _Environment Variables_).  If this environment variable
           is not present, the results of the search are implementation-
           defined.
    
           There are two distinct ways in which the contents of the process
           image file may cause the execution to fail, distinguished by the
           setting of _errno_ to either **[ENOEXEC]** or **[EINVAL]**(see the ERRORS
           section). In the cases where the other members of the _exec_ family
           of functions would fail and set _errno_ to **[ENOEXEC]** , the _execlp_()
           and _execvp_() functions shall execute a command interpreter and the
           environment of the executed command shall be as if the process
           invoked the _sh_ utility using _execl_() as follows:
    
               execl(<shell path>, arg0, file, arg1, ..., (char *)0);
    
           where <_shell path_ > is an unspecified pathname for the _sh_ utility,
           _file_ is the process image file, and for _execvp_(), where _arg_ 0,
           _arg_ 1, and so on correspond to the values passed to _execvp_() in
           _argv_[0], _argv_[1], and so on.
    
           The arguments represented by _arg0_ ,...  are pointers to null-
           terminated character strings. These strings shall constitute the
           argument list available to the new process image. The list is
           terminated by a null pointer. The argument _arg0_ should point to a
           filename string that is associated with the process being started
           by one of the _exec_ functions.
    
           The argument _argv_ is an array of character pointers to null-
           terminated strings. The application shall ensure that the last
           member of this array is a null pointer. These strings shall
           constitute the argument list available to the new process image.
           The value in _argv_[0] should point to a filename string that is
           associated with the process being started by one of the _exec_
           functions.
    
           The argument _envp_ is an array of character pointers to null-
           terminated strings. These strings shall constitute the environment
           for the new process image.  The _envp_ array is terminated by a null
           pointer.
    
           For those forms not containing an _envp_ pointer (_execl_(), _execv_(),
           _execlp_(), and _execvp_()), the environment for the new process image
           shall be taken from the external variable _environ_ in the calling
           process.
    
           The number of bytes available for the new process' combined
           argument and environment lists is {ARG_MAX}.  It is
           implementation-defined whether null terminators, pointers, and/or
           any alignment bytes are included in this total.
    
           File descriptors open in the calling process image shall remain
           open in the new process image, except for those whose close-on-
           _exec_ flag FD_CLOEXEC is set.  For those file descriptors that
           remain open, all attributes of the open file description remain
           unchanged. For any file descriptor that is closed for this reason,
           file locks are removed as a result of the close as described in
           _close_().  Locks that are not removed by closing of file
           descriptors remain unchanged.
    
           If file descriptor 0, 1, or 2 would otherwise be closed after a
           successful call to one of the _exec_ family of functions,
           implementations may open an unspecified file for the file
           descriptor in the new process image. If a standard utility or a
           conforming application is executed with file descriptor 0 not open
           for reading or with file descriptor 1 or 2 not open for writing,
           the environment in which the utility or application is executed
           shall be deemed non-conforming, and consequently the utility or
           application might not behave as described in this standard.
    
           Directory streams open in the calling process image shall be
           closed in the new process image.
    
           The state of the floating-point environment in the initial thread
           of the new process image shall be set to the default.
    
           The state of conversion descriptors and message catalog
           descriptors in the new process image is undefined.
    
           For the new process image, the equivalent of:
    
               setlocale(LC_ALL, "C")
    
           shall be executed at start-up.
    
           Signals set to the default action (SIG_DFL) in the calling process
           image shall be set to the default action in the new process image.
           Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the
           calling process image shall be set to be ignored by the new
           process image. Signals set to be caught by the calling process
           image shall be set to the default action in the new process image
           (see _< signal.h>_).
    
           If the SIGCHLD signal is set to be ignored by the calling process
           image, it is unspecified whether the SIGCHLD signal is set to be
           ignored or to the default action in the new process image.
    
           After a successful call to any of the _exec_ functions, alternate
           signal stacks are not preserved and the SA_ONSTACK flag shall be
           cleared for all signals.
    
           After a successful call to any of the _exec_ functions, any
           functions previously registered by the _atexit_() or
           _pthread_atfork_() functions are no longer registered.
    
           If the ST_NOSUID bit is set for the file system containing the new
           process image file, then the effective user ID, effective group
           ID, saved set-user-ID, and saved set-group-ID are unchanged in the
           new process image. Otherwise, if the set-user-ID mode bit of the
           new process image file is set, the effective user ID of the new
           process image shall be set to the user ID of the new process image
           file. Similarly, if the set-group-ID mode bit of the new process
           image file is set, the effective group ID of the new process image
           shall be set to the group ID of the new process image file. The
           real user ID, real group ID, and supplementary group IDs of the
           new process image shall remain the same as those of the calling
           process image. The effective user ID and effective group ID of the
           new process image shall be saved (as the saved set-user-ID and the
           saved set-group-ID) for use by _setuid_().
    
           Any shared memory segments attached to the calling process image
           shall not be attached to the new process image.
    
           Any named semaphores open in the calling process shall be closed
           as if by appropriate calls to _sem_close_().
    
           Any blocks of typed memory that were mapped in the calling process
           are unmapped, as if _munmap_() was implicitly called to unmap them.
    
           Memory locks established by the calling process via calls to
           _mlockall_() or _mlock_() shall be removed. If locked pages in the
           address space of the calling process are also mapped into the
           address spaces of other processes and are locked by those
           processes, the locks established by the other processes shall be
           unaffected by the call by this process to the _exec_ function. If
           the _exec_ function fails, the effect on memory locks is
           unspecified.
    
           Memory mappings created in the process are unmapped before the
           address space is rebuilt for the new process image.
    
           When the calling process image does not use the SCHED_FIFO,
           SCHED_RR, or SCHED_SPORADIC scheduling policies, the scheduling
           policy and parameters of the new process image and the initial
           thread in that new process image are implementation-defined.
    
           When the calling process image uses the SCHED_FIFO, SCHED_RR, or
           SCHED_SPORADIC scheduling policies, the process policy and
           scheduling parameter settings shall not be changed by a call to an
           _exec_ function.  The initial thread in the new process image shall
           inherit the process scheduling policy and parameters. It shall
           have the default system contention scope, but shall inherit its
           allocation domain from the calling process image.
    
           Per-process timers created by the calling process shall be deleted
           before replacing the current process image with the new process
           image.
    
           All open message queue descriptors in the calling process shall be
           closed, as described in _mq_close_().
    
           Any outstanding asynchronous I/O operations may be canceled. Those
           asynchronous I/O operations that are not canceled shall complete
           as if the _exec_ function had not yet occurred, but any associated
           signal notifications shall be suppressed. It is unspecified
           whether the _exec_ function itself blocks awaiting such I/O
           completion. In no event, however, shall the new process image
           created by the _exec_ function be affected by the presence of
           outstanding asynchronous I/O operations at the time the _exec_
           function is called. Whether any I/O is canceled, and which I/O may
           be canceled upon _exec_ , is implementation-defined.
    
           The new process image shall inherit the CPU-time clock of the
           calling process image. This inheritance means that the process
           CPU-time clock of the process being _exec_ -ed shall not be
           reinitialized or altered as a result of the _exec_ function other
           than to reflect the time spent by the process executing the _exec_
           function itself.
    
           The initial value of the CPU-time clock of the initial thread of
           the new process image shall be set to zero.
    
           If the calling process is being traced, the new process image
           shall continue to be traced into the same trace stream as the
           original process image, but the new process image shall not
           inherit the mapping of trace event names to trace event type
           identifiers that was defined by calls to the
           _posix_trace_eventid_open_() or the _posix_trace_trid_eventid_open_()
           functions in the calling process image.
    
           If the calling process is a trace controller process, any trace
           streams that were created by the calling process shall be shut
           down as described in the _posix_trace_shutdown_() function.
    
           The thread ID of the initial thread in the new process image is
           unspecified.
    
           The size and location of the stack on which the initial thread in
           the new process image runs is unspecified.
    
           The initial thread in the new process image shall have its
           cancellation type set to PTHREAD_CANCEL_DEFERRED and its
           cancellation state set to PTHREAD_CANCEL_ENABLED.
    
           The initial thread in the new process image shall have all thread-
           specific data values set to NULL and all thread-specific data keys
           shall be removed by the call to _exec_ without running destructors.
    
           The initial thread in the new process image shall be joinable, as
           if created with the _detachstate_ attribute set to
           PTHREAD_CREATE_JOINABLE.
    
           The new process shall inherit at least the following attributes
           from the calling process image:
    
            *  Nice value (see _nice_())
    
            *  _semadj_ values (see _semop_())
    
            *  Process ID
    
            *  Parent process ID
    
            *  Process group ID
    
            *  Session membership
    
            *  Real user ID
    
            *  Real group ID
    
            *  Supplementary group IDs
    
            *  Time left until an alarm clock signal (see _alarm_())
    
            *  Current working directory
    
            *  Root directory
    
            *  File mode creation mask (see _umask_())
    
            *  File size limit (see _getrlimit_() and _setrlimit_())
    
            *  Process signal mask (see _pthread_sigmask_())
    
            *  Pending signal (see _sigpending_())
    
            *  _tms_utime_ , _tms_stime_ , _tms_cutime_ , and _tms_cstime_ (see _times_())
    
            *  Resource limits
    
            *  Controlling terminal
    
            *  Interval timers
    
           The initial thread of the new process shall inherit at least the
           following attributes from the calling thread:
    
            *  Signal mask (see _sigprocmask_() and _pthread_sigmask_())
    
            *  Pending signals (see _sigpending_())
    
           All other process attributes defined in this volume of
           POSIX.1‐2017 shall be inherited in the new process image from the
           old process image. All other thread attributes defined in this
           volume of POSIX.1‐2017 shall be inherited in the initial thread in
           the new process image from the calling thread in the old process
           image.  The inheritance of process or thread attributes not
           defined by this volume of POSIX.1‐2017 is implementation-defined.
    
           A call to any _exec_ function from a process with more than one
           thread shall result in all threads being terminated and the new
           executable image being loaded and executed. No destructor
           functions or cleanup handlers shall be called.
    
           Upon successful completion, the _exec_ functions shall mark for
           update the last data access timestamp of the file. If an _exec_
           function failed but was able to locate the process image file,
           whether the last data access timestamp is marked for update is
           unspecified. Should the _exec_ function succeed, the process image
           file shall be considered to have been opened with _open_().  The
           corresponding _close_() shall be considered to occur at a time after
           this open, but before process termination or successful completion
           of a subsequent call to one of the _exec_ functions, _posix_spawn_(),
           or _posix_spawnp_().  The _argv_[] and _envp_[] arrays of pointers and
           the strings to which those arrays point shall not be modified by a
           call to one of the _exec_ functions, except as a consequence of
           replacing the process image.
    
           The saved resource limits in the new process image are set to be a
           copy of the process' corresponding hard and soft limits.
    


## RETURN VALUE



           If one of the _exec_ functions returns to the calling process image,
           an error has occurred; the return value shall be -1, and _errno_
           shall be set to indicate the error.
    


## ERRORS



           The _exec_ functions shall fail if:
    
           **E2BIG** The number of bytes used by the new process image's
                  argument list and environment list is greater than the
                  system-imposed limit of {ARG_MAX} bytes.
    
           **EACCES** The new process image file is not a regular file and the
                  implementation does not support execution of files of its
                  type.
    
           **EINVAL** The new process image file has appropriate privileges and
                  has a recognized executable binary format, but the system
                  does not support execution of a file with this format.
    
           The _exec_ functions, except for _fexecve_(), shall fail if:
    
           **EACCES** Search permission is denied for a directory listed in the
                  new process image file's path prefix, or the new process
                  image file denies execution permission.
    
           **ELOOP** A loop exists in symbolic links encountered during
                  resolution of the _path_ or _file_ argument.
    
           **ENAMETOOLONG**
                  The length of a component of a pathname is longer than
                  {NAME_MAX}.
    
           **ENOENT** A component of _path_ or _file_ does not name an existing file
                  or _path_ or _file_ is an empty string.
    
           **ENOTDIR**
                  A component of the new process image file's path prefix
                  names an existing file that is neither a directory nor a
                  symbolic link to a directory, or the new process image
                  file's pathname contains at least one non-<slash> character
                  and ends with one or more trailing <slash> characters and
                  the last pathname component names an existing file that is
                  neither a directory nor a symbolic link to a directory.
    
           The _exec_ functions, except for _execlp_() and _execvp_(), shall fail
           if:
    
           **ENOEXEC**
                  The new process image file has the appropriate access
                  permission but has an unrecognized format.
    
           The _fexecve_() function shall fail if:
    
           **EBADF** The _fd_ argument is not a valid file descriptor open for
                  executing.
    
           The _exec_ functions may fail if:
    
           **ENOMEM** The new process image requires more memory than is allowed
                  by the hardware or system-imposed memory management
                  constraints.
    
           The _exec_ functions, except for _fexecve_(), may fail if:
    
           **ELOOP** More than {SYMLOOP_MAX} symbolic links were encountered
                  during resolution of the _path_ or _file_ argument.
    
           **ENAMETOOLONG**
                  The length of the _path_ argument or the length of the
                  pathname constructed from the _file_ argument exceeds
                  {PATH_MAX}, or pathname resolution of a symbolic link
                  produced an intermediate result with a length that exceeds
                  {PATH_MAX}.
    
           **ETXTBSY**
                  The new process image file is a pure procedure (shared
                  text) file that is currently open for writing by some
                  process.
    
           _The following sections are informative._
    


## EXAMPLES



       **Using execl()**
           The following example executes the _ls_ command, specifying the
           pathname of the executable (**/bin/ls**) and using arguments supplied
           directly to the command to produce single-column output.
    
               #include <unistd.h>
    
               int ret;
               ...
               ret = execl ("/bin/ls", "ls", "-1", (char *)0);
    
       **Using execle()**
           The following example is similar to _Using execl()_.  In addition,
           it specifies the environment for the new process image using the
           _env_ argument.
    
               #include <unistd.h>
    
               int ret;
               char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
               ...
               ret = execle ("/bin/ls", "ls", "-l", (char *)0, env);
    
       **Using execlp()**
           The following example searches for the location of the _ls_ command
           among the directories specified by the _PATH_ environment variable.
    
               #include <unistd.h>
    
               int ret;
               ...
               ret = execlp ("ls", "ls", "-l", (char *)0);
    
       **Using execv()**
           The following example passes arguments to the _ls_ command in the
           _cmd_ array.
    
               #include <unistd.h>
    
               int ret;
               char *cmd[] = { "ls", "-l", (char *)0 };
               ...
               ret = execv ("/bin/ls", cmd);
    
       **Using execve()**
           The following example passes arguments to the _ls_ command in the
           _cmd_ array, and specifies the environment for the new process image
           using the _env_ argument.
    
               #include <unistd.h>
    
               int ret;
               char *cmd[] = { "ls", "-l", (char *)0 };
               char *env[] = { "HOME=/usr/home", "LOGNAME=home", (char *)0 };
               ...
               ret = execve ("/bin/ls", cmd, env);
    
       **Using execvp()**
           The following example searches for the location of the _ls_ command
           among the directories specified by the _PATH_ environment variable,
           and passes arguments to the _ls_ command in the _cmd_ array.
    
               #include <unistd.h>
    
               int ret;
               char *cmd[] = { "ls", "-l", (char *)0 };
               ...
               ret = execvp ("ls", cmd);
    


## APPLICATION USAGE



           As the state of conversion descriptors and message catalog
           descriptors in the new process image is undefined, conforming
           applications should not rely on their use and should close them
           prior to calling one of the _exec_ functions.
    
           Applications that require other than the default POSIX locale as
           the global locale in the new process image should call _setlocale_()
           with the appropriate parameters.
    
           When assigning a new value to the _environ_ variable, applications
           should ensure that the environment to which it will point contains
           at least the following:
    
            1. Any implementation-defined variables required by the
               implementation to provide a conforming environment. See the
               _CS_V7_ENV entry in _< unistd.h>_ and _confstr_() for details.
    
            2. A value for _PATH_ which finds conforming versions of all
               standard utilities before any other versions.
    
           The same constraint applies to the _envp_ array passed to _execle_()
           or _execve_(), in order to ensure that the new process image is
           invoked in a conforming environment.
    
           Applications should not execute programs with file descriptor 0
           not open for reading or with file descriptor 1 or 2 not open for
           writing, as this might cause the executed program to misbehave. In
           order not to pass on these file descriptors to an executed
           program, applications should not just close them but should reopen
           them on, for example, **/dev/null**.  Some implementations may reopen
           them automatically, but applications should not rely on this being
           done.
    
           If an application wants to perform a checksum test of the file
           being executed before executing it, the file will need to be
           opened with read permission to perform the checksum test.
    
           Since execute permission is checked by _fexecve_(), the file
           description _fd_ need not have been opened with the O_EXEC flag.
           However, if the file to be executed denies read and write
           permission for the process preparing to do the _exec_ , the only way
           to provide the _fd_ to _fexecve_() will be to use the O_EXEC flag when
           opening _fd_.  In this case, the application will not be able to
           perform a checksum test since it will not be able to read the
           contents of the file.
    
           Note that when a file descriptor is opened with O_RDONLY, O_RDWR,
           or O_WRONLY mode, the file descriptor can be used to read, read
           and write, or write the file, respectively, even if the mode of
           the file changes after the file was opened. Using the O_EXEC open
           mode is different; _fexecve_() will ignore the mode that was used
           when the file descriptor was opened and the _exec_ will fail if the
           mode of the file associated with _fd_ does not grant execute
           permission to the calling process at the time _fexecve_() is called.
    


## RATIONALE



           Early proposals required that the value of _argc_ passed to _main_()
           be ``one or greater''. This was driven by the same requirement in
           drafts of the ISO C standard.  In fact, historical implementations
           have passed a value of zero when no arguments are supplied to the
           caller of the _exec_ functions. This requirement was removed from
           the ISO C standard and subsequently removed from this volume of
           POSIX.1‐2017 as well. The wording, in particular the use of the
           word _should_ , requires a Strictly Conforming POSIX Application to
           pass at least one argument to the _exec_ function, thus guaranteeing
           that _argc_ be one or greater when invoked by such an application.
           In fact, this is good practice, since many existing applications
           reference _argv_[0] without first checking the value of _argc_.
    
           The requirement on a Strictly Conforming POSIX Application also
           states that the value passed as the first argument be a filename
           string associated with the process being started. Although some
           existing applications pass a pathname rather than a filename
           string in some circumstances, a filename string is more generally
           useful, since the common usage of _argv_[0] is in printing
           diagnostics. In some cases the filename passed is not the actual
           filename of the file; for example, many implementations of the
           _login_ utility use a convention of prefixing a <hyphen-minus> (**'‐'**)
           to the actual filename, which indicates to the command interpreter
           being invoked that it is a ``login shell''.
    
           Also, note that the _test_ and _[_ utilities require specific strings
           for the _argv_[0] argument to have deterministic behavior across all
           implementations.
    
           Historically, there have been two ways that implementations can
           _exec_ shell scripts.
    
           One common historical implementation is that the _execl_(), _execv_(),
           _execle_(), and _execve_() functions return an **[ENOEXEC]** error for any
           file not recognizable as executable, including a shell script.
           When the _execlp_() and _execvp_() functions encounter such a file,
           they assume the file to be a shell script and invoke a known
           command interpreter to interpret such files.  This is now required
           by POSIX.1‐2008. These implementations of _execvp_() and _execlp_()
           only give the **[ENOEXEC]** error in the rare case of a problem with
           the command interpreter's executable file. Because of these
           implementations, the **[ENOEXEC]** error is not mentioned for _execlp_()
           or _execvp_(), although implementations can still give it.
    
           Another way that some historical implementations handle shell
           scripts is by recognizing the first two bytes of the file as the
           character string **"#!"** and using the remainder of the first line of
           the file as the name of the command interpreter to execute.
    
           One potential source of confusion noted by the standard developers
           is over how the contents of a process image file affect the
           behavior of the _exec_ family of functions. The following is a
           description of the actions taken:
    
            1. If the process image file is a valid executable (in a format
               that is executable and valid and having appropriate
               privileges) for this system, then the system executes the
               file.
    
            2. If the process image file has appropriate privileges and is in
               a format that is executable but not valid for this system
               (such as a recognized binary for another architecture), then
               this is an error and _errno_ is set to **[EINVAL]**(see later
               RATIONALE on **[EINVAL]**).
    
            3. If the process image file has appropriate privileges but is
               not otherwise recognized:
    
                a. If this is a call to _execlp_() or _execvp_(), then they
                   invoke a command interpreter assuming that the process
                   image file is a shell script.
    
                b. If this is not a call to _execlp_() or _execvp_(), then an
                   error occurs and _errno_ is set to **[ENOEXEC]**.
    
           Applications that do not require to access their arguments may use
           the form:
    
               main(void)
    
           as specified in the ISO C standard. However, the implementation
           will always provide the two arguments _argc_ and _argv_ , even if they
           are not used.
    
           Some implementations provide a third argument to _main_() called
           _envp_.  This is defined as a pointer to the environment. The ISO C
           standard specifies invoking _main_() with two arguments, so
           implementations must support applications written this way. Since
           this volume of POSIX.1‐2017 defines the global variable _environ_ ,
           which is also provided by historical implementations and can be
           used anywhere that _envp_ could be used, there is no functional need
           for the _envp_ argument. Applications should use the _getenv_()
           function rather than accessing the environment directly via either
           _envp_ or _environ_.  Implementations are required to support the two-
           argument calling sequence, but this does not prohibit an
           implementation from supporting _envp_ as an optional third argument.
    
           This volume of POSIX.1‐2017 specifies that signals set to SIG_IGN
           remain set to SIG_IGN, and that the new process image inherits the
           signal mask of the thread that called _exec_ in the old process
           image. This is consistent with historical implementations, and it
           permits some useful functionality, such as the _nohup_ command.
           However, it should be noted that many existing applications
           wrongly assume that they start with certain signals set to the
           default action and/or unblocked. In particular, applications
           written with a simpler signal model that does not include blocking
           of signals, such as the one in the ISO C standard, may not behave
           properly if invoked with some signals blocked. Therefore, it is
           best not to block or ignore signals across _exec_ s without explicit
           reason to do so, and especially not to block signals across _exec_ s
           of arbitrary (not closely cooperating) programs.
    
           The _exec_ functions always save the value of the effective user ID
           and effective group ID of the process at the completion of the
           _exec_ , whether or not the set-user-ID or the set-group-ID bit of
           the process image file is set.
    
           The statement about _argv_[] and _envp_[] being constants is included
           to make explicit to future writers of language bindings that these
           objects are completely constant. Due to a limitation of the ISO C
           standard, it is not possible to state that idea in standard C.
           Specifying two levels of _const_ -_qualification_ for the _argv_[] and
           _envp_[] parameters for the _exec_ functions may seem to be the
           natural choice, given that these functions do not modify either
           the array of pointers or the characters to which the function
           points, but this would disallow existing correct code.  Instead,
           only the array of pointers is noted as constant. The table of
           assignment compatibility for _dst_ =_src_ derived from the ISO C
           standard summarizes the compatibility:
    ┌─────────────────────┬──────────┬────────────────┬───────────────┬─────────────────────┐
    │                _dst_ : │ **char *[]** │ **const char *[]** │ **char *const[]** │ **const char *const[]** │
    ├─────────────────────┼──────────┼────────────────┼───────────────┼─────────────────────┤
    │ _src_**:** │          │                │               │                     │
    │ **char *[]** │  VALID   │       —        │     VALID     │          —          │
    │ **const char *[]** │    —     │     VALID      │       —       │        VALID        │
    │ **char * const []** │    —     │       —        │     VALID     │          —          │
    │ **const char *const[]** │    —     │       —        │       —       │        VALID        │
    └─────────────────────┴──────────┴────────────────┴───────────────┴─────────────────────┘
    
           Since all existing code has a source type matching the first row,
           the column that gives the most valid combinations is the third
           column. The only other possibility is the fourth column, but using
           it would require a cast on the _argv_ or _envp_ arguments. It is
           unfortunate that the fourth column cannot be used, because the
           declaration a non-expert would naturally use would be that in the
           second row.
    
           The ISO C standard and this volume of POSIX.1‐2017 do not conflict
           on the use of _environ_ , but some historical implementations of
           _environ_ may cause a conflict. As long as _environ_ is treated in the
           same way as an entry point (for example, _fork_()), it conforms to
           both standards. A library can contain _fork_(), but if there is a
           user-provided _fork_(), that _fork_() is given precedence and no
           problem ensues. The situation is similar for _environ_ : the
           definition in this volume of POSIX.1‐2017 is to be used if there
           is no user-provided _environ_ to take precedence. At least three
           implementations are known to exist that solve this problem.
    
           **E2BIG** The limit {ARG_MAX} applies not just to the size of the
                  argument list, but to the sum of that and the size of the
                  environment list.
    
           **EFAULT** Some historical systems return **[EFAULT]** rather than
                  **[ENOEXEC]** when the new process image file is corrupted.
                  They are non-conforming.
    
           **EINVAL** This error condition was added to POSIX.1‐2008 to allow an
                  implementation to detect executable files generated for
                  different architectures, and indicate this situation to the
                  application. Historical implementations of shells,
                  _execvp_(), and _execlp_() that encounter an **[ENOEXEC]** error
                  will execute a shell on the assumption that the file is a
                  shell script. This will not produce the desired effect when
                  the file is a valid executable for a different
                  architecture. An implementation may now choose to avoid
                  this problem by returning **[EINVAL]** when a valid executable
                  for a different architecture is encountered.  Some
                  historical implementations return **[EINVAL]** to indicate that
                  the _path_ argument contains a character with the high order
                  bit set. The standard developers chose to deviate from
                  historical practice for the following reasons:
    
                        1. The new utilization of **[EINVAL]** will provide some
                           measure of utility to the user community.
    
                        2. Historical use of **[EINVAL]** is not acceptable in an
                           internationalized operating environment.
    
           **ENAMETOOLONG**
                  Since the file pathname may be constructed by taking
                  elements in the _PATH_ variable and putting them together
                  with the filename, the **[ENAMETOOLONG]** error condition could
                  also be reached this way.
    
           **ETXTBSY**
                  System V returns this error when the executable file is
                  currently open for writing by some process. This volume of
                  POSIX.1‐2017 neither requires nor prohibits this behavior.
    
           Other systems (such as System V) may return **[EINTR]** from _exec_.
           This is not addressed by this volume of POSIX.1‐2017, but
           implementations may have a window between the call to _exec_ and the
           time that a signal could cause one of the _exec_ calls to return
           with **[EINTR]**.
    
           An explicit statement regarding the floating-point environment (as
           defined in the _< fenv.h>_ header) was added to make it clear that
           the floating-point environment is set to its default when a call
           to one of the _exec_ functions succeeds. The requirements for
           inheritance or setting to the default for other process and thread
           start-up functions is covered by more generic statements in their
           descriptions and can be summarized as follows:
    
           _posix_spawn (3p) 14_
                  Set to default.
    
           _fork (3p) 14_
                  Inherit.
    
           _pthread_create (3p) 14_
                  Inherit.
    
           The purpose of the _fexecve_() function is to enable executing a
           file which has been verified to be the intended file. It is
           possible to actively check the file by reading from the file
           descriptor and be sure that the file is not exchanged for another
           between the reading and the execution. Alternatively, a function
           like _openat_() can be used to open a file which has been found by
           reading the content of a directory using _readdir_().
    


## FUTURE DIRECTIONS



           None.
    


* * *