EXEC(3)

✨ EXEC(3) ✨

okay bestie, so the library functions manual is literally about the whole exec squad — execl, execlp, execle, exect, execv, execvp, execvpe, and execvP — and they're all about executing a file 💅.

🎀 LIBRARY 🎀

Standard C Library (libc, -lc) — the way that it's just sitting there in libc, iconic.

🦋 SYNOPSIS 🦋

#include <unistd.h>

extern char **environ;

int
execl(const char *path, const char *arg, ..., NULL);

int
execlp(const char *file, const char *arg, ..., NULL);

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

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

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

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

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

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

💖 DESCRIPTION 💖

so the exec family of functions replaces the current process image with a brand new process image. literally a whole glow-up for your process. the functions described in this manual page are front-ends for the function execve(2). (check the manual page for execve(2) for all the deets about replacing the current process, iykyk.)

the initial argument for these functions is the <italic>pathname</italic> of a file which is to be executed. main character behavior only.

the const char *<italic>arg</italic> and subsequent ellipses in the execl(), execlp(), and execle() functions can be thought of as <italic>arg0</italic>, <italic>arg1</italic>, ..., <italic>argn</italic>. together they describe a list of one or more pointers to null-terminated strings that represent the argument list available to the executed program. the first argument, by convention, should point to the file name associated with the file being executed. the list of arguments must be terminated by a NULL pointer. no cap, that NULL is mandatory.

the exect(), execv(), execvp(), execvpe(), and execvP() functions provide an array of pointers to null-terminated strings that represent the argument list available to the new program. the first argument, by convention, should point to the file name associated with the file being executed. the array of pointers must be terminated by a NULL pointer. same vibes, different data structure bestie.

the execle(), exect(), and execvpe() functions also specify the environment of the executed process by following the NULL pointer that terminates the list of arguments in the argument list or the pointer to the <italic>argv</italic> array with an additional argument. this additional argument is an array of pointers to null-terminated strings and must be terminated by a NULL pointer. the other functions take the environment for the new process image from the external variable environ in the current process. it's giving "borrowed environment energy."

some of these functions have special semantics. not me getting into the lore 🫶.

🌸 the search path situation 🌸

the functions execlp(), execvp(), execvpe(), and execvP() will duplicate the actions of the shell in searching for an executable file if the specified file name does not contain a slash “/” character. for execlp() and execvp(), execvpe(), search path is the path specified in the environment by “PATH” variable. if this variable is not specified, the default path is set according to the _PATH_DEFPATH definition in <paths.h>, which is set to:

“/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin”

for execvP(), the search path is specified as an argument to the function. in addition, certain errors are treated specially. highkey important stuff.

if an error is ambiguous (for simplicity, we shall consider all errors except ENOEXEC as being ambiguous here, although only the critical error EACCES is really ambiguous), then these functions will act as if they stat the file to determine whether the file exists and has suitable execute permissions. if it does, they will return immediately with the global variable errno restored to the value set by execve(). otherwise, the search will be continued. if the search completes without performing a successful execve() or terminating due to an error, these functions will return with the global variable errno set to EACCES or ENOENT according to whether at least one file with suitable execute permissions was found. the way that this is just so specific 😭.

if the header of a file is not recognized (the attempted execve() returned ENOEXEC), these functions will execute the shell with the path of the file as its first argument. (if this attempt fails, no further searching is done.) slay, fallback queen.

the function exect() executes a file with the program tracing facilities enabled (see ptrace(2)). detective mode activated 🔥.

👑 RETURN VALUES 👑

if any of the exec() functions returns, an error will have occurred. the return value is -1, and the global variable errno will be set to indicate the error. so like, if you see a return, something went wrong bestie. periodt.

🍓 FILES 🍓

• /bin/sh — the shell. that's it. that's the file. 💅

🌈 COMPATIBILITY 🌈

historically, the default path for the execlp() and execvp() functions was “:/bin:/usr/bin”. this was changed to remove the current directory to enhance system security. glow-up for safety ✨.

the behavior of execlp() and execvp() when errors occur while attempting to execute the file is not quite historic practice, and has not traditionally been documented and is not specified by the POSIX standard. it's giving "mystery behavior."

traditionally, the functions execlp() and execvp() ignored all errors except for the ones described above and ETXTBSY, upon which they retried after sleeping for several seconds, and ENOMEM and E2BIG, upon which they returned. they now return for ETXTBSY, and determine existence and executability more carefully. in particular, EACCES for inaccessible directories in the path prefix is no longer confused with EACCES for files with unsuitable execute permissions. in 4.4BSD, they returned upon all errors except EACCES, ENOENT, ENOEXEC and ETXTBSY. this was inferior to the traditional error handling, since it breaks the ignoring of errors for path prefixes and only improves the handling of the unusual ambiguous error EFAULT and the unusual error EIO. the behaviour was changed to match the behaviour of sh(1). ngl the history is kinda messy but we respect the journey 🫶.

⭐ ERRORS ⭐

the execl(), execle(), execlp(), execvp(), execvpe(), and execvP() functions may fail and set errno for any of the errors specified for the library functions execve(2) and malloc(3). so many possible errors, but that's just how it is.

the exect() and execv() functions may fail and set errno for any of the errors specified for the library function execve(2). simpler error list for these two, lowkey.

💜 SEE ALSO 💜

sh(1), execve(2), fork(2), ktrace(2), ptrace(2), environ(7) — go read these if you wanna understand the whole ecosystem, iykyk.

🧚 STANDARDS 🧚

the execl(), execv(), execle(), execlp() and execvp() functions conform to IEEE Std 1003.1-1988 (“POSIX.1”). the execvpe() function is a GNU extension. different vibes, different standards, we love to see it.

🌸 HISTORY 🌸

the exec() function appeared in Version 1 AT&T UNIX. the execl() and execv() functions appeared in Version 2 AT&T UNIX. the execlp(), execle(), execve(), and execvp() functions appeared in Version 7 AT&T UNIX. the execvP() function first appeared in FreeBSD 5.2. the execvpe() function first appeared in FreeBSD 14.1. the way that this family has been evolving since the literal beginning of UNIX ✨ iconic lineage.

🎀 BUGS 🎀

the type of the <italic>argv</italic> and <italic>envp</italic> parameters to execle(), exect(), execv(), execvp(), execvpe(), and execvP() is a historical accident and no sane implementation should modify the provided strings. the bogus parameter types trigger false positives from const correctness analyzers. on FreeBSD, the __DECONST() macro may be used to work around this limitation. not me side-eyeing the type system 💀.

due to a fluke of the C standard, on platforms other than FreeBSD the definition of NULL may be the untyped number zero, rather than a (void *)0 expression. to distinguish the concepts, they are referred to as a “null pointer constant” and a “null pointer”, respectively. on exotic computer architectures that FreeBSD does not support, the null pointer constant and null pointer may have a different representation. in general, where this document and others reference a NULL value, they actually imply a null pointer. e.g., for portability to non-FreeBSD operating systems on exotic computer architectures, one may use (char *)NULL in place of NULL when invoking execl(), execle(), and execlp(). the C standard really said "let's make this confusing" and we just have to live with it 😭.

---

okay so that's literally the whole exec(3) man page bestie, you're welcome 💖✨ this was giving "Debian" energy, December 11, 2023, and the source is the library functions manual — go forth and exec responsibly 🫶🎀