Exec (system call)

{{Short description|Execute a file (a library function and/or a system call)}}

{{about|the computer operating system function|other uses|Exec (disambiguation)|the programming language function that executes a statement|eval}}

In computing, exec is a functionality of an operating system that runs an executable file in the context of an already existing process, replacing the previous executable. This act is also referred to as an overlay. It is especially important in Unix-like systems, although it also exists elsewhere. As no new process is created, the process identifier (PID) does not change, but the machine code, data, heap, and stack of the process are replaced by those of the new program.

The exec call or some variant is available for many programming languages including compiled languages and some scripting languages. In command interpreters, the {{Code|exec|sh}} built-in command replaces the shell process with the specified program.{{man|3|exec}}

Nomenclature

Interfaces to exec and its implementations vary. Depending on programming language it may be accessible via one or more functions, and depending on operating system it may be represented with one or more actual system calls. For this reason, exec is sometimes described as a collection of functions.

In C, there is no single, plain {{Code|exec|}} function. The Linux kernel has one corresponding system call named {{Code|execve}}, whereas all other functions are user-space wrappers around it.

High-level programming languages usually provide one call named {{code|exec}}.

In Unix, POSIX, and other multitasking systems

=C language prototypes=

The POSIX standard declares a family of exec functions in the {{mono|unistd.h}} header file. The same functions are declared in {{mono|process.h}} for DOS (see below), OS/2, and Microsoft Windows.

int execl(char const *path, char const *arg0, ...);

int execle(char const *path, char const *arg0, ..., char const *envp[]);

int execlp(char const *file, char const *arg0, ...);

int execv(char const *path, char const *argv[]);

int execve(char const *path, char const *argv[], char const *envp[]);

int execvp(char const *file, char const *argv[]);

int execvpe(const char *file, char *const argv[], char *const envp[]);

int fexecve(int fd, char *const argv[], char *const envp[]);

Some implementations provide these functions named with a leading underscore (e.g. {{code|_execl}}).{{Cite web |last=Whitney |first=Tyler |title=_exec, _wexec Functions |url=https://learn.microsoft.com/en-us/cpp/c-runtime-library/exec-wexec-functions?view=msvc-170#remarks |access-date=2025-05-26 |website=learn.microsoft.com |language=en-us}}

The base of each is exec, followed by one or more letters:

{{Mono|e}} – Environment variables are passed as an array of pointers to null-terminated strings of form {{code|name=|name{{=}}value}}. The final element of the array must be a null pointer.{{man|3|execve}}
{{Mono|l}} – Command-line arguments are passed as individual pointers to null-terminated strings. The last argument must be a null pointer.
{{Mono|p}} – Uses the PATH environment variable to find the file named in the file argument to be executed.
{{Mono|v}} – Command-line arguments are passed as an array of pointers to null-terminated strings. The final element of the array must be a null pointer.
{{Mono|f}} (prefix) – A file descriptor is passed instead. The file descriptor must be opened with {{var|O_RDONLY}} or {{var|O_PATH}} and the caller must have permission to execute its file.{{man|3|fexecve}}

In functions where no environment variables can be passed ({{code|execl}}, {{code|execlp}}, {{code|execv}}, {{code|execvp}}), the new process image inherits the current environment variables.

== First command-line argument ==

The first argument {{var|arg0}} is often the name of the executable file and may be the same value as the {{Var|path}} argument. However, this is purely convention and there is no guarantee of this behavior, nor is it standardized. For instance, in Java, the first argument is not the path to the executable, but instead the first argument for the program.{{Cite web |title=Java - Your Application Launcher - Dev.java |url=https://dev.java/learn/jvm/tools/core/java/ |access-date=2025-05-26 |website=Dev.java: The Destination for Java Developers |language=en}}

=Effects=

A file descriptor open when an exec call is made remains open in the new process image, unless fcntl was called with {{var|FD_CLOEXEC}} or opened with {{var|O_CLOEXEC}} (the latter was introduced in POSIX.1-2001). This aspect is used to specify the standard streams of the new program.

A successful overlay destroys the previous memory address space of the process. All of its memory areas that were not shared are reclaimed by the operating system. Consequently, all its data that were not passed to the new program, or otherwise saved, are lost.

=Return value=

A successful call replaces the current process image, so it cannot return anything to the program that made the call. Processes do have an exit status, but that value is collected by the parent process.

If the call fails, the return value is always -1, and errno is set to an appropriate value.{{Man|3|execve|SUS}}

In DOS

DOS is not a multitasking operating system, but replacing the previous executable image is essential due to harsh primary memory limitations and lack of virtual memory. The same API is used for overlaying programs in DOS and it has effects similar to ones on POSIX systems.

MS-DOS exec functions always load the new program into memory as if the "maximum allocation" in the program's executable file header is set to default value of 0xFFFF. The EXEHDR utility can be used to change the maximum allocation field of a program. However, if this is done and the program is invoked with one of the exec functions, the program might behave differently from a program invoked directly from the operating-system command line or with one of the spawn functions (see below).

In shells

Many Unix shells also offer a builtin {{mono|exec}} command that replaces the shell process with the specified program.{{Cite web |last=Sharma |first=Sagar |date=2023-05-28 |title=Using exec Command in Bash Shell Scripts [4 Examples] |url=https://linuxhandbook.com/exec-command-shell-scripts/ |access-date=2025-05-26 |website=Linux Handbook |language=en}} Wrapper scripts often use this command to run a program (either directly or through an interpreter or virtual machine) after setting environment variables or other configuration. By using exec, the resources used by the shell program do not need to stay in use after the program is started.{{cite web |url=http://tldp.org/LDP/abs/html/wrapper.html |title=Shell Wrappers |date=2014-03-10 |publisher=Linux Documentation Project |access-date=2021-02-18}}

The command can also perform a redirection. In some shells, it is possible to use it for redirection only, without making an actual overlay.

In other systems

OS/360 and successors include a system call {{Code|XCTL}} (transfer control) that performs a similar function to exec.{{Cite web |title=XCTL |url=https://www.ibm.com/docs/en/cics-tx/11.1.0?topic=commands-xctl |access-date=2025-05-26 |website=www.ibm.com |language=en-us}}

Versus spawning

The traditional Unix system does not have the functionality to create a new process running a new executable program in one step. Other systems may use spawn as the main tool for running executables. Its result is equivalent to the fork–exec sequence of Unix-like systems. POSIX supports the posix_spawn routines as an optional extension that usually is implemented using vfork.{{man|3|posix_spawn}}