execl(), execle(), execlp(), execv(), execve(), execvp() - execute a file
#include <unistd.h>
extern char **environ;
int execl (const char *path, const char *arg ...)
int execle (const char *path, const char *arg ... char *const envp[])
int execlp (const char *file, const char *arg ...)
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[])
The exec(2) family of functions replaces the current process image with a new process image. The first argument is the name of the file to be executed; most of the functions require a full path name, but execlp(2) and execvp(2) will search the directories named in the PATH environment variable.
The second argument to the function is the argument vector (represented in a C main() function by argv The execl functions take a const char * argument, while the execv* functions take a char *const array as the argument. The third argument, where present, is an environment for the new process image. For execl(2), execv(2), execlp(2), and execvp(2), the new process image inherits the environment of the calling process image, stored in extern char **environ
The arguments are:
const char *
path
#! interpreter [arguments]
For more information about interpreter files, see Interpreter Files
later in this reference page.const char *
file
(
/ the call constructs the path name by searching the
directories named in the PATH environment variable.
Once the file is found, the exec functions try to execute it as a POSIX process, then as a Win32 process, and last as an interpreter file.
const char *
arg ...
This argument is treated slightly differently by execle(2): after the NULL pointer, there is another character pointer which contains the new process's environment, as if it were declared as
char *const envp[]
char *const
argv[]
char *const
envp[]
The total space available for the combined argument and environment lists of the new process image is {ARG_MAX}.
When the call succeeds, it creates a new process image; if the new process is a C program, the entry point is main where argc is the number of elements in the argument list (not counting the terminating NULL pointer) and argv is the argument list itself. The functions also set up
extern char **environ
which contains the process's environment.
Once these calls have successfully completed, they mark the st_atime field of path, since it was successfully open(2)'ed.
Here are the guidelines as to which attributes and resources are and are not inherited by the new process:
Calling Process Attribute | Behavior |
---|---|
Open file descriptors | Remain open, unless close-on-exec flag FD_CLOEXEC is set |
Directory streams | Closed |
Signals set to default action | Set to default action |
Signals set to be ignored | Set to be ignored |
Signals set to be caught | Set to default action |
Real user ID | Inherited |
Real group ID | Inherited |
Supplementary group ID | Inherited |
Effective user ID | Inherited, unless path has set-user-ID set. Interix must be configured to execute files with set-user-ID set; see [ENOSETUID] in ERRORS later in this topic. |
Effective group ID | Inherited, unless path has set-group-ID set. Interix must be configured to execute files with set-group-ID set; see [ENOSETUID] in ERRORS later in this topic. |
Process ID | Inherited |
Parent process ID | Inherited |
Process group ID | Inherited |
Session membership | Inherited |
Time left until alarm clock signal | Inherited |
Current working directory | Inherited |
Root directory | Inherited |
File mode creation mask | Inherited |
Process signal mask | Inherited |
Pending signals | Inherited |
If the saved-set-user-ID mode bit is set on the new process image file, then the effective user ID of the new process image is set to the owner ID of the file.
If the saved-set-group-ID mode bit is set on the new process image file, then the effective group ID of the new process image is set to the group ID of the file.
If {_POSIX_SAVED_IDS} is defined, the effective user ID and the effective group ID are saved for use by the setuid(2) function.
If the file specified by path is a text file and the first line has the form:
#! interpreter [arguments]
then the exec functions run the program specified by
interpreter with the given arguments The maximum
length of the line is 255 characters; the interpreter can be
invoked with as many arguments as will fit on the command line.
The interpreter line specifies an interpreter according to the following rules:
The first line can be recursive; that is, interpreter can specify a file that begins with a #! interpreter line, and so on, nested eight levels. For each level, the exec functions first try to create a process image of the file as a POSIX executable, then as a Win32 executable, and last as an interpreter file.
A POSIX process can exec a Win32 image file, but there are several limitations.
The POSIX process will remain in the Interix subsystem's process table until the corresponding Win32 process exits. The exit status of this process will always indicate a normal return, as if by a call to exit(3), with the exit value being the low order 8 bits of the Win32 process's 32 bit exit status. There is currently no way to detect the fact that a Win32 process was terminated by an exception.
None of the processes spawned by the Win32 process will show up in the Interix subsystem's process table.
All POSIX signals sent to the Win32 process are ignored.
If the Win32 process is a console application, then the only file descriptors that can be inherited are file descriptors 0, 1 and 2, corresponding to the Win32 standard input, standard output and standard error. The only types of file descriptors that can be inherited are those associated with a regular file, a controlling console tty, a controlling pseudo tty (stdout and stderr only), /dev/null, or a pipe.
If the Win32 process is a graphical user interface application, no file descriptors are inherited.
If the Windows security token (which corresponds to the POSIX real UID) of the Win32 process is that of the interactive user, then any windows created by the process will be visible on the screen. Otherwise, the windows will be invisible and non-interactive. Win32 processes spawned from a telnet(1) session, a POSIX service program, or a process whose real UID was set by a call to exec*_asuser do not have the ability to create interactive windows.
A POSIX process cannot exec DOS, Win16 or OS/2 image files.
On success, the exec functions don't return. If they fail, they set errno and return -1.
The exec functions can set errno to any of the following values:
The exec functions will fail if the setuid or setgid bit is set on the file being executed and if the file's mode bits allow it to be written by anyone other than the owner.
sh(1)
exit(3)
fork(2)