6a:T4df,#include #include void using_list_variant() { // Known at compile time: exactly 3 arguments // execl(path, arg0, arg1, arg2, NULL) execl("/bin/ls", "ls", "-l", "-a", NULL); // arg0 is conventionally the program name } void using_vector_variant(int argc, char *argv[]) { // Runtime-determined arguments // Useful when forwarding arguments from another program // Build argument vector dynamically char *my_args[argc + 1]; // +1 for NULL terminator my_args[0] = "myprogram"; // arg0 = program name for (int i = 1; i < argc; i++) { my_args[i] = argv[i]; // Copy arguments } my_args[argc] = NULL; // NULL terminator required execv("/path/to/myprogram", my_args); } void shell_command_example() { // Real-world example: building a grep command dynamically char *pattern = "error"; // Could come from user input char *file = "/var/log/syslog"; // Could be dynamic // With list variant - awkward for dynamic arguments: execl("/bin/grep", "grep", pattern, file, NULL); // With vector variant - natural for dynamic arguments: char *grep_args[] = {"grep", pattern, file, NULL}; execv("/bin/grep", grep_args); }6b:T7ad,#include #include #include // The global environ variable holds current environment extern char **environ; int main() { // Non-'e' variant: child inherits parent's environment execl("/usr/bin/env", "env", NULL); // Child sees all of parent's environment variables // 'e' variant: specify environment explicitly char *custom_env[] = { "PATH=/usr/bin:/bin", "HOME=/tmp", "MY_APP_MODE=production", "DATABASE_URL=postgres://localhost/mydb", NULL // NULL terminator required }; execle("/usr/bin/env", "env", NULL, custom_env); // Child sees ONLY the four variables we specified // Parent's other variables are NOT inherited perror("exec failed"); return 1; } // Security: creating a clean environment void secure_exec() { // For setuid programs or security-sensitive operations, // never inherit the untrusted environment char *safe_env[] = { "PATH=/usr/bin:/bin", // Known-safe PATH "IFS= \t ", // Safe IFS "HOME=/tmp", // Neutral home NULL }; // Execute with controlled environment only execve("/path/to/secure/program", argv, safe_env); } // Augmenting the environment void add_to_environment() { // Sometimes you want parent's environment PLUS some additions // This requires constructing a new array int env_count = 0; for (char **e = environ; *e != NULL; e++) { env_count++; } // Create new array: original + 2 new + NULL terminator char *new_env[env_count + 3]; // Copy existing environment for (int i = 0; i < env_count; i++) { new_env[i] = environ[i]; } // Add new variables new_env[env_count] = "MY_NEW_VAR=value"; new_env[env_count + 1] = "ANOTHER_VAR=other"; new_env[env_count + 2] = NULL; execve("/path/to/program", argv, new_env); }6c:T441,**What happens inside the kernel when execve() is called:** 1. **Pathname resolution**: The kernel resolves the pathname to an inode 2. **Permission checks**: - Is the file executable? - Does the calling process have execute permission? - Is the filesystem mounted with `noexec`? 3. **File format recognition**: - Is it an ELF binary? → Load using ELF loader - Is it a script with `#!` (shebang)? → Invoke the interpreter - Other formats check (a.out, etc.) 4. **Memory space preparation**: - Allocate new memory regions - Release old text, data, heap, stack segments - Load new program's segments 5. **Security transitions**: - Apply setuid/setgid if applicable - Clear capabilities as appropriate - Reset signal dispositions to default for caught signals 6. **Stack setup**: - Copy argv strings to new stack - Copy envp strings to new stack - Set up initial stack frame 7. **Jump to entry point**: - Transfer control to the new program's `_start` symbol - `_start` initializes runtime, then calls `main(argc, argv, environ)`6d:T86a,#include #include #include #include // MISTAKE 1: Forgetting the NULL terminator void mistake_no_null() { // WRONG: No NULL terminator - undefined behavior! execl("/bin/ls", "ls", "-l"); // Missing NULL // CORRECT: execl("/bin/ls", "ls", "-l", NULL); } // MISTAKE 2: Using wrong pathname vs filename void mistake_path_type() { // WRONG with non-'p' variant: execl("ls", "ls", "-l", NULL); // "ls" is not a path! // This looks for "./ls" or fails // CORRECT: Use 'p' variant for name-only execlp("ls", "ls", "-l", NULL); // Or specify full path for non-'p': execl("/bin/ls", "ls", "-l", NULL); } // MISTAKE 3: Ignoring exec failure void mistake_no_error_check() { // WRONG: No error handling execl("/bin/nonexistent", "nonexistent", NULL); // If we reach here, exec failed, but we don't know why printf("continuing normally... "); // Bad! // CORRECT: Always check for failure execl("/bin/nonexistent", "nonexistent", NULL); // If we reach here, exec definitely failed fprintf(stderr, "exec failed: %s ", strerror(errno)); exit(1); // Or handle error appropriately } // MISTAKE 4: Expecting exec to return on success void mistake_expect_return() { execl("/bin/ls", "ls", NULL); // WRONG EXPECTATION: This code never runs on success! printf("ls finished "); // Never printed if exec succeeds } // MISTAKE 5: Wrong arg0 convention void mistake_arg0() { // UNUSUAL (but valid): arg0 doesn't match program name execl("/bin/busybox", "ls", "-l", NULL); // This actually runs busybox, which uses arg0 to decide behavior // Works for busybox, but confusing for regular programs // CONVENTION: arg0 should be the program name execl("/bin/ls", "ls", "-l", NULL); } // MISTAKE 6: Modifying strings in argv (they should be const-ish) void mistake_modify_argv() { char *args[] = {"prog", "arg1", NULL}; // Some programs might try to modify argv for ps display // But exec copies these strings, so modifications after // exec setup are lost anyway }62:{"json":{"id":"seed_5eedfda2647681711f0c3d03c4bdac3e","slug":"exec-family","category":"Operating Systems","topic":"Process Creation & Termination","title":"The exec() Family of System Calls","description":"Master the exec() family of system calls that form the second half of Unix process creation. Learn how exec() replaces a process image, understand all major variants (execl, execv, execle, execve, execlp, execvp), and discover the iconic fork-exec pattern that underpins every program launch in Unix-like systems.","difficulty":"INTERMEDIATE","estimatedMinutes":55,"pages":[{"id":"seed_935784fb98b3325b0a90a6f920e57071","title":"exec() Variants","order":0,"content":[{"id":"opening-hook","title":"The Other Half of Process Creation","content":[{"data":{"content":"In the previous module, we explored `fork()`—the system call that creates a new process by duplicating the calling process. But here's a critical question: **if fork() just makes a copy of the parent, how do we ever run a different program?**\n\nThe answer lies in the `exec()` family of system calls. While `fork()` creates a new process, `exec()` *transforms* it. Together, they form the complete Unix process creation mechanism—a design so elegant and flexible that it has survived virtually unchanged for over 50 years.\n\nBut `exec()` isn't a single system call. It's a family of related functions, each with subtle differences that serve specific use cases. Understanding these variants—and knowing which to use when—separates confident systems programmers from those who guess and check."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand every major exec() variant, decode their naming conventions, recognize their semantic differences, and know exactly which variant to use for any given situation. You'll see why this apparent complexity actually provides elegant flexibility.","variant":"info"},"type":"callout"}]},{"id":"exec-concept","title":"The exec() Concept","content":[{"data":{"content":"Before diving into variants, let's establish what `exec()` fundamentally does. The exec() system call performs a complete **process image replacement**. When a process calls exec():\n\n1. The current process's text (code) segment is replaced with the new program's code\n2. The data segment is replaced with the new program's initialized data\n3. The BSS segment is replaced with the new program's uninitialized data\n4. The heap is discarded and replaced with the new program's heap\n5. The stack is discarded and replaced with a fresh stack for the new program\n\n**What remains unchanged:**\n- The Process ID (PID)\n- The Parent Process ID (PPID)\n- Open file descriptors (unless marked close-on-exec)\n- Current working directory\n- Root directory\n- Process group ID and session ID\n- Real user ID and real group ID\n- Pending signals\n- Resource limits\n- Controlling terminal"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Key Insight","content":"exec() does not create a new process—it transforms an existing one. The process retains its identity (PID) but completely changes its behavior. Think of it as a caterpillar becoming a butterfly: same organism, entirely different form.","variant":"tip"},"type":"callout"},{"data":{"code":"#include \n#include \n\nint main() {\n printf(\"Before exec: PID = %d\n\", getpid());\n \n // This replaces the entire process image with /bin/ls\n // If exec succeeds, the following line NEVER executes\n execl(\"/bin/ls\", \"ls\", \"-l\", NULL);\n \n // Only reached if exec fails\n perror(\"exec failed\");\n return 1;\n}","fileName":"exec_basic_concept.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**Critical observation:** If `exec()` succeeds, it never returns. The calling code is completely replaced by the new program. The only time exec() returns is when it fails—and in that case, it returns -1 and sets `errno`.\n\nThis \"no return on success\" semantic is unlike almost any other function in C. It's a one-way door: once you exec(), there's no coming back to your original code."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"naming-convention","title":"The Naming Convention","content":[{"data":{"content":"The exec() family follows a systematic naming convention that encodes the function's behavior in its name. Once you understand this convention, you can decode any exec variant instantly.\n\nEvery variant starts with `exec` followed by one or more suffix letters:"},"type":"text"},{"data":{"rows":[["`l`","**list**","Arguments passed as a list (varargs)"],["`v`","**vector**","Arguments passed as an array (char *argv[])"],["`e`","**environment**","Environment passed explicitly as parameter"],["`p`","**path**","Uses PATH environment variable to find executable"]],"headers":["Suffix","Meaning","Effect"]},"type":"table"},{"data":{"content":"These suffixes combine to form the complete set of exec variants:"},"type":"text"},{"data":{"rows":[["`execl`","list","inherited","no","`execl(path, arg0, arg1, ..., NULL)`"],["`execv`","vector","inherited","no","`execv(path, argv[])`"],["`execle`","list","explicit","no","`execle(path, arg0, ..., NULL, envp[])`"],["`execve`","vector","explicit","no","`execve(path, argv[], envp[])`"],["`execlp`","list","inherited","yes","`execlp(file, arg0, arg1, ..., NULL)`"],["`execvp`","vector","inherited","yes","`execvp(file, argv[])`"],["`execvpe`","vector","explicit","yes","`execvpe(file, argv[], envp[])`"]],"caption":"The Complete exec() Family","headers":["Function","Arguments","Environment","Path Search","Signature"]},"type":"table"},{"data":{"icon":"Info","title":"The Fundamental System Call","content":"Among all these variants, only `execve()` is an actual system call. All others are library wrappers that ultimately call execve(). This is why execve() has both 'v' and 'e' in its name—it requires both explicit argument vector and explicit environment.","variant":"note"},"type":"callout"},{"data":{"height":"350px","mermaidSyntax":"flowchart TD\n subgraph \"Library Functions\"\n execl[\"execl()\"]\n execv[\"execv()\"]\n execle[\"execle()\"]\n execlp[\"execlp()\"]\n execvp[\"execvp()\"]\n execvpe[\"execvpe()\"]\n end\n \n subgraph \"System Call\"\n execve[\"execve() - Actual System Call\"]\n end\n \n execl --> execve\n execv --> execve\n execle --> execve\n execlp --> execve\n execvp --> execve\n execvpe --> execve\n \n style execve fill:#22c55e,color:#fff"},"type":"mermaid-excalidraw"}],"titleType":"number","titleNumber":2},{"id":"list-vs-vector","title":"List vs Vector: The 'l' and 'v' Variants","content":[{"data":{"content":"The most fundamental distinction in the exec() family is how arguments are passed. This comes down to compile-time knowledge: **do you know the number of arguments when writing the code, or is it determined at runtime?**"},"type":"text"},{"data":{"left":[{"data":{"items":["Arguments passed as separate parameters","Use C's variadic function mechanism","Must end with NULL sentinel","Number of arguments known at compile time","Convenient for fixed-argument commands","Easier to read for simple cases"],"title":{"icon":"Code2","text":"List Variants (execl, execlp, execle)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Arguments passed as array of strings","Array must be NULL-terminated","Number of arguments determined at runtime","Essential for dynamic argument construction","Used when forwarding command-line args","More flexible for complex scenarios"],"title":{"icon":"Code2","text":"Vector Variants (execv, execvp, execvpe)","type":"icon","color":"secondary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"code":"$6a","fileName":"list_vs_vector.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"The NULL Terminator is Critical","content":"Both list and vector variants MUST have a NULL terminator. For list variants, the last argument must be (char *)NULL. For vector variants, the array must end with a NULL pointer. Omitting this causes undefined behavior—potentially reading garbage memory as arguments.","variant":"warning"},"type":"callout"},{"data":{"content":"**Practical guidance:**\n\n- Use **list variants** when executing a fixed command with known arguments (like running `ls -l`)\n- Use **vector variants** when:\n - Arguments are constructed dynamically\n - You're forwarding arguments from `main(argc, argv)`\n - The argument count is determined at runtime\n - You're building a shell or command executor"},"type":"text"}],"titleType":"number","titleNumber":3},{"id":"path-search","title":"Path Search: The 'p' Variants","content":[{"data":{"content":"The 'p' suffix variants (`execlp`, `execvp`, `execvpe`) add a crucial capability: **PATH environment variable searching**. This is how your shell finds commands without requiring full paths.\n\n**How path search works:**\n\n1. If the filename contains a slash (`/`), it's treated as a path (no search performed)\n2. Otherwise, the directories in PATH are searched in order\n3. The first executable match is used\n4. If no match is found, exec fails with `ENOENT`"},"type":"text"},{"data":{"code":"#include \n#include \n#include \n\nint main() {\n // WITHOUT path search - must specify full path\n execl(\"/usr/bin/python3\", \"python3\", \"--version\", NULL);\n \n // Error: if python3 isn't at exactly /usr/bin/python3, this fails\n \n // WITH path search - searches PATH automatically\n execlp(\"python3\", \"python3\", \"--version\", NULL);\n \n // This checks each directory in PATH:\n // 1. /usr/local/bin/python3? No\n // 2. /usr/bin/python3? Yes! Execute it.\n \n perror(\"exec failed\");\n return 1;\n}\n\n// Demonstrating the search behavior explicitly\nvoid show_path_search() {\n // Assume PATH=/usr/local/bin:/usr/bin:/bin\n \n // execlp(\"ls\", ...) searches:\n // /usr/local/bin/ls - not found\n // /usr/bin/ls - not found \n // /bin/ls - FOUND! Execute.\n \n // execlp(\"/bin/ls\", ...) does NOT search\n // because the filename contains '/'\n // It tries /bin/ls directly (same as execl)\n}","fileName":"path_search_example.c","showLineNumbers":true},"type":"code"},{"data":{"left":[{"data":{"items":["Executing standard system commands","Building shell-like interfaces","User specifies command by name","Portability across different systems","Command location may vary"],"title":{"icon":"CheckCircle","text":"Use 'p' Variants When","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Security-sensitive operations","You know the exact executable path","PATH manipulation is a concern","Running your own application binaries","Reproducibility is critical"],"title":{"icon":"XCircle","text":"Avoid 'p' Variants When","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"AlertCircle","title":"Security Warning: PATH Attacks","content":"The 'p' variants introduce security risks. An attacker who can modify PATH could redirect your exec to a malicious binary. For security-critical code (setuid programs, daemons, etc.), always use full paths with non-'p' variants. Never trust PATH in security contexts.","variant":"error"},"type":"callout"},{"data":{"content":"**The conffile vs. PATH distinction:**\n\nNotice that 'p' variants take a `file` parameter while others take a `path` parameter. This isn't just terminology:\n\n- `path` = a pathname (absolute or relative), used as-is\n- `file` = a filename that may be searched for in PATH\n\nIf `file` contains no slashes, PATH is searched. If it contains a slash (like `./myprogram` or `/usr/bin/python`), it's used directly as a path."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"environment-control","title":"Environment Control: The 'e' Variants","content":[{"data":{"content":"The 'e' suffix variants (`execle`, `execve`, `execvpe`) allow you to **specify the environment for the new process explicitly**. Without the 'e', the new program inherits the current process's environment unchanged."},"type":"text"},{"data":{"content":"**Why control the environment?**\n\nEnvironment variables configure program behavior in foundational ways:\n- `PATH` – where to find executables\n- `HOME` – user's home directory\n- `USER` – current username\n- `LANG`/`LC_*` – localization settings\n- `LD_LIBRARY_PATH` – dynamic library search path\n- Application-specific settings (`DATABASE_URL`, `API_KEY`, etc.)\n\nSometimes you need to:\n- **Sanitize** the environment for security (remove dangerous variables)\n- **Augment** the environment (add variables for child process)\n- **Replace** the environment entirely (controlled sandbox)\n- **Pass secrets** securely to child processes"},"type":"text"},{"data":{"code":"$6b","fileName":"environment_control.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Environment Array Format","content":"The environment array (envp) follows the same format as argv: a NULL-terminated array of strings. Each string has the format 'NAME=value' (no spaces around the equals sign). The array must be NULL-terminated.","variant":"tip"},"type":"callout"},{"data":{"rows":[["`execl`, `execv`, `execlp`, `execvp`","Inherits parent's `environ` automatically","Normal program execution"],["`execle`, `execve`, `execvpe`","Uses explicitly provided `envp` array","Security, sandboxing, configuration"]],"caption":"Environment Inheritance in exec() Variants","headers":["Variant","Environment Behavior","Use Case"]},"type":"table"}],"titleType":"number","titleNumber":5},{"id":"execve-system-call","title":"The Core System Call: execve()","content":[{"data":{"content":"`execve()` is the **only actual system call** in the exec() family. All other variants are C library functions that eventually call `execve()`. Understanding execve() means understanding the fundamental interface to the kernel."},"type":"text"},{"data":{"code":"#include \n\n// The actual system call signature\nint execve(const char *pathname, // Full path to executable\n char *const argv[], // Argument vector (NULL-terminated)\n char *const envp[]); // Environment vector (NULL-terminated)\n\n// Returns: -1 on error (only return case), sets errno\n// On success: does not return (process image replaced)","fileName":"execve_signature.c","showLineNumbers":true},"type":"code"},{"data":{"content":"$6c"},"type":"text"},{"data":{"height":"450px","mermaidSyntax":"sequenceDiagram\n participant P as Process\n participant K as Kernel\n participant FS as Filesystem\n participant MM as Memory Manager\n \n P->>K: execve(\"/bin/ls\", argv, envp)\n K->>FS: Resolve pathname\n FS-->>K: Inode reference\n K->>K: Check permissions\n K->>K: Identify file format (ELF)\n K->>MM: Release old memory regions\n K->>MM: Map new text segment\n K->>MM: Map new data segment\n K->>K: Set up new stack with argv, envp\n K->>P: Jump to _start entry point\n Note over P: Process is now running /bin/ls\nOld program code is gone"},"type":"mermaid-excalidraw"},{"data":{"icon":"Info","title":"The Point of No Return","content":"Once execve() begins modifying the process memory, there's no undo. The old program is gone. If something fails during the loading process, the kernel must terminate the process rather than restore it—there's nothing left to restore. This is why exec() is atomic: it either succeeds completely or fails without any effect.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"variant-reference","title":"Complete Variant Reference","content":[{"data":{"content":"Let's examine each exec() variant with its complete signature, behavior, and typical use case."},"type":"text"},{"data":{"tabs":[{"id":"execl","label":"execl()","content":[{"data":{"code":"int execl(const char *pathname, const char *arg0, \n ..., /* more args */ (char *)NULL);\n\n// Example:\nexecl(\"/bin/ls\", \"ls\", \"-l\", \"-a\", \"/home\", NULL);\n\n// - pathname: Full path to executable\n// - arg0: Conventionally the program name\n// - ...: Additional arguments as separate parameters\n// - Must end with (char *)NULL\n\n// Use when: Known command with fixed arguments","showLineNumbers":true},"type":"code"},{"data":{"content":"**execl()** is the simplest variant for executing a program when you know the full path and all arguments at compile time. The 'l' denotes list-style argument passing using C's variadic function mechanism."},"type":"text"}],"titleIcon":"Code2"},{"id":"execv","label":"execv()","content":[{"data":{"code":"int execv(const char *pathname, char *const argv[]);\n\n// Example:\nchar *args[] = {\"ls\", \"-l\", \"-a\", \"/home\", NULL};\nexecv(\"/bin/ls\", args);\n\n// - pathname: Full path to executable\n// - argv: NULL-terminated array of argument strings\n// - argv[0] conventionally holds program name\n\n// Use when: Arguments constructed at runtime","showLineNumbers":true},"type":"code"},{"data":{"content":"**execv()** passes arguments as a vector (array). Essential when the number of arguments is determined at runtime, such as when building a command from user input or forwarding arguments received from main()."},"type":"text"}],"titleIcon":"Code2"},{"id":"execle","label":"execle()","content":[{"data":{"code":"int execle(const char *pathname, const char *arg0,\n ..., (char *)NULL, char *const envp[]);\n\n// Example:\nchar *env[] = {\"PATH=/usr/bin\", \"HOME=/tmp\", NULL};\nexecle(\"/bin/ls\", \"ls\", \"-l\", NULL, env);\n\n// - pathname: Full path to executable \n// - arg0, ...: List of arguments ending with NULL\n// - envp: NULL-terminated array of environment strings\n// - Note: envp comes AFTER the NULL terminator for args\n\n// Use when: Need explicit environment with fixed arguments","showLineNumbers":true},"type":"code"},{"data":{"content":"**execle()** combines list-style arguments with explicit environment control. Note the unusual signature: the environment array comes after the NULL that terminates the argument list. This is a common source of bugs—don't forget that NULL!"},"type":"text"}],"titleIcon":"Code2"},{"id":"execve","label":"execve()","content":[{"data":{"code":"int execve(const char *pathname, char *const argv[],\n char *const envp[]);\n\n// Example:\nchar *args[] = {\"ls\", \"-l\", NULL};\nchar *env[] = {\"PATH=/usr/bin\", \"HOME=/tmp\", NULL};\nexecve(\"/bin/ls\", args, env);\n\n// - pathname: Full path to executable\n// - argv: NULL-terminated argument array\n// - envp: NULL-terminated environment array\n\n// THE ONLY ACTUAL SYSTEM CALL\n// All other exec functions ultimately call this","showLineNumbers":true},"type":"code"},{"data":{"content":"**execve()** is the fundamental system call that all others reduce to. If you need maximum control or are writing systems code, this is the variant to use. It requires both explicit argument vector and explicit environment."},"type":"text"}],"titleIcon":"Code2"},{"id":"execlp","label":"execlp()","content":[{"data":{"code":"int execlp(const char *file, const char *arg0,\n ..., (char *)NULL);\n\n// Example:\nexeclp(\"python3\", \"python3\", \"script.py\", NULL);\n\n// - file: Filename (searches PATH if no '/' present)\n// - arg0, ...: List of arguments ending with NULL\n// - Environment inherited from parent\n\n// Use when: Running standard commands by name\n// Searches PATH for the executable","showLineNumbers":true},"type":"code"},{"data":{"content":"**execlp()** is the go-to for running system utilities by name without knowing their exact location. The 'p' enables PATH searching, making it behave like typing a command in a shell."},"type":"text"}],"titleIcon":"Code2"},{"id":"execvp","label":"execvp()","content":[{"data":{"code":"int execvp(const char *file, char *const argv[]);\n\n// Example:\nchar *args[] = {\"python3\", \"script.py\", \"-v\", NULL};\nexecvp(\"python3\", args);\n\n// - file: Filename (searches PATH if no '/' present)\n// - argv: NULL-terminated argument array\n// - Environment inherited from parent\n\n// Most common for shell implementations\n// Dynamic args + PATH search = maximum flexibility","showLineNumbers":true},"type":"code"},{"data":{"content":"**execvp()** combines the flexibility of vector arguments with PATH searching. This is the variant most often used in shell implementations where both the command and arguments come from user input."},"type":"text"}],"titleIcon":"Code2"},{"id":"execvpe","label":"execvpe()","content":[{"data":{"code":"int execvpe(const char *file, char *const argv[],\n char *const envp[]);\n\n// Example (GNU extension, not POSIX):\nchar *args[] = {\"python3\", \"script.py\", NULL};\nchar *env[] = {\"PATH=/usr/bin\", \"PYTHONPATH=/app\", NULL};\nexecvpe(\"python3\", args, env);\n\n// - file: Filename (searches PATH from envp, not parent's PATH!)\n// - argv: NULL-terminated argument array\n// - envp: NULL-terminated environment array\n\n// Note: PATH search uses the PATH in envp, not current process","showLineNumbers":true},"type":"code"},{"data":{"content":"**execvpe()** provides the ultimate combination: vector arguments, custom environment, AND path searching. Note: it's a GNU extension, not part of POSIX. The PATH used for searching is taken from the envp you provide, not the current process's environment."},"type":"text"}],"titleIcon":"Code2"}],"defaultTab":"execve"},"type":"tabs"}],"titleType":"number","titleNumber":7},{"id":"errors-pitfalls","title":"Common Errors and Pitfalls","content":[{"data":{"content":"The exec() functions have several subtle error conditions and common mistakes that can derail even experienced programmers."},"type":"text"},{"data":{"rows":[["`ENOENT`","No such file or directory","Wrong path, file doesn't exist, or command not found in PATH"],["`EACCES`","Permission denied","File not executable, or directory in path not searchable"],["`ENOEXEC`","Exec format error","File is not a valid executable (wrong architecture, corrupt binary)"],["`E2BIG`","Argument list too long","argv + envp exceeds system limit (typically 2MB on Linux)"],["`ENOMEM`","Out of memory","Insufficient memory to create new process image"],["`ETXTBSY`","Text file busy","Executable is open for writing by another process"],["`EFAULT`","Bad address","argv or envp points to invalid memory"],["`ELOOP`","Too many symbolic links","Symlink chain is too deep or circular"]],"caption":"Common exec() Errors (errno values)","headers":["errno","Meaning","Common Cause"]},"type":"table"},{"data":{"code":"$6d","fileName":"common_mistakes.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"The \"Reached After Exec\" Pattern","content":"Any code that appears after an exec() call will only run if exec() failed. This means you should always have error handling after exec(). A common defensive pattern is to call _exit(127) after exec() fails, mimicking shell behavior for command-not-found (127 is the conventional exit code).","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":8},{"id":"choosing-variant","title":"Choosing the Right Variant","content":[{"data":{"content":"With seven variants to choose from, how do you pick the right one? Here's a decision framework:"},"type":"text"},{"data":{"height":"500px","mermaidSyntax":"flowchart TD\n Start([Choose exec variant]) --> Q1{Are arguments\nknown at\ncompile time?}\n \n Q1 -->|Yes| Q2{Need PATH\nsearch?}\n Q1 -->|No| Q3{Need PATH\nsearch?}\n \n Q2 -->|Yes| Q4{Need custom\nenvironment?}\n Q2 -->|No| Q5{Need custom\nenvironment?}\n \n Q3 -->|Yes| Q6{Need custom\nenvironment?}\n Q3 -->|No| Q7{Need custom\nenvironment?}\n \n Q4 -->|No| execlp[execlp]\n Q4 -->|Yes| manual1[execlp + manual\nenv setup]\n \n Q5 -->|No| execl[execl]\n Q5 -->|Yes| execle[execle]\n \n Q6 -->|No| execvp[execvp]\n Q6 -->|Yes| execvpe[execvpe\nGNU only]\n \n Q7 -->|No| execv[execv]\n Q7 -->|Yes| execve[execve]\n \n style execve fill:#22c55e,color:#fff\n style execvp fill:#3b82f6,color:#fff"},"type":"mermaid-excalidraw"},{"data":{"items":["**Most flexible (default choice):** `execvp()` — vector args + PATH search, covers most use cases","**Maximum control:** `execve()` — the system call itself, explicit everything","**Simple known command:** `execl()` — clean syntax for fixed commands","**Shell implementation:** `execvp()` — dynamic args from parsed input + PATH search","**Security-sensitive:** `execve()` — full path, explicit controlled environment","**Quick system utility:** `execlp()` — easy PATH search with fixed args"],"title":{"icon":"Target","text":"Quick Selection Guide","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Lightbulb","title":"When in Doubt","content":"If you're unsure, start with `execvp()`. It handles the most common case (runtime args + PATH search) and you can always switch to a more specialized variant if needed. Only use `execve()` when you specifically need environment control or are writing security-sensitive code.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":9},{"id":"summary","title":"Summary: The exec() Family","content":[{"data":{"content":"We've thoroughly explored the exec() family of functions. Let's consolidate the key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**exec() replaces the process image** — The calling program is completely replaced; only the PID survives.","**exec() never returns on success** — If you see code after exec(), it only runs on failure.","**execve() is the only system call** — All six other variants are library wrappers that ultimately call execve().","**'l' vs 'v'**: List (compile-time args) vs Vector (runtime args array).","**'p' enables PATH search** — Finds executables like a shell does; introduces security considerations.","**'e' provides explicit environment** — Control what environment the new program sees.","**Always include NULL terminators** — Both argument lists and arrays must be NULL-terminated.","**Always check for failure** — Handle errors after every exec() call."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that you understand what exec() does and which variant to use, the next page dives deep into *how* exec() works internally. We'll explore the complete process of replacing a process image—from releasing old memory regions to loading new program segments to setting up the initial stack. Understanding this mechanism is essential for debugging exec() issues and appreciating the elegance of Unix process creation."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the complete exec() family: seven variants, their naming conventions, semantic differences, and appropriate use cases. You can decode any exec variant instantly and choose the right one for any situation. Next, we'll explore how process image replacement actually works at the system level.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":10}],"isLocked":false},{"id":"seed_397e88bb5aced4a40c04c05b0507e428","title":"Replacing the Process Image","order":1,"content":null,"isLocked":true},{"id":"seed_428838788b6ceb3984e9d3a58900b861","title":"Argument Passing","order":2,"content":null,"isLocked":true},{"id":"seed_5d8ab3e699ed5ad4f130366e39391b94","title":"Environment Variables","order":3,"content":null,"isLocked":true},{"id":"seed_78c0d9b5cfed54c85bc83190ce4b2880","title":"The Fork-Exec Pattern","order":4,"content":null,"isLocked":true}]}}