Linux Process Control--exec function family

Original: http://www.cnblogs.com/hnrainll/archive/2011/07/23/2114854.html

1. Introduction

in Linux, there is no exec () function, and exec refers to a set of functions, a total of 6, respectively:#include <unistd.h>extern char **environ;int execl (const char *path, const char *arg, ...);int EXECLP (const char *file, const char *arg, ...);int execle (const char *path, const char *arg, ..., char * const envp[]);int execv (const char *path, char *const argv[]);int EXECVP (const char *file, char *const argv[]);int Execve (const char *path, char *const argv[], char *const envp[]); only Execve is the real system call, and the others are packaged library functions on this basis. the function of the EXEC function family is to find the executable file according to the specified file name and use it to replace the contents of the calling process , in other words, execute an executable file inside the calling process . The executable file here can be either a binary file or a script file that can be executed under any Linux. the relationship between the function name and the parameter:after a closer look, these 6 functions are all starting with the Exec (representing the EXEC function group), the first 3 functions followed by the letter L, and the last 3 followed by the letter V, I understand that L is the list (enumeration parameters), V is the vector (parameter vector table). The difference is that the function at the beginning of EXECV is to pass command-line arguments as "char *argv[" (vector), and the function at the beginning of the EXECL takes a list (list), lists the parameters one by one, and ends with a null representation. The null effect here is the same as the null function in the argv array. The letter P refers to the directory where the environment variable path is located to find the executable file to execute. The 2 functions EXECLP and EXECVP, which end in P, seem to differ very little from those of Execl and execv, and they differ from the first parameter name: 4 functions except EXECLP and EXECVP are required, Their 1th parameter path must be a complete path, such as "/bin/ls", while the 1th parameter of EXECLP and EXECVP file can be just a file name, such as "LS", these two functions can be automatically to the environment variable path specified in the directory to find. the letter E refers to the environment variable specified for the executable file. Of all 6 functions, only execle and Execve use char *envp[] to pass the environment variable, and none of the other 4 functions have this parameter, which does not mean that they do not pass the environment variable, and these 4 functions will pass the default environment variable to the executed application without any modification. Instead, execle and EXECVE use the specified environment variables to override the default ones. return valueUnlike the general case, the function of the EXEC function family does not return after successful execution, because the entity that invokes the process, including the code snippet, data segment, and stack, has been replaced with new content, and only some surface information, such as the process ID, remains intact. when the call fails, it sets the errno and returns 1, then executes from the original program's call Point . in contrast to other system calls, exec is prone to failure, the location of files being executed, permissions, and many other factors that can cause a call to fail. Therefore, when using the EXEC function family, be sure to add an error judgment statement. The most common errors are:file or path not found, at this time errno is set to Enoent;array argv and envp forget to end with NULL, at this point errno is set to Efault;There is no run permission on the file to be executed, at which point the errno is set to Eacces. 2. ApplicationIf a process wants to execute another program, it can fork or vfork out a new process, and then call any of the exec functions. for this reason, Linux is also optimized for fork: Usually fork copies all the contents of the calling process into the newly generated sub-process, which consumes time, and if we call exec immediately after the fork is finished, The hard copy will be erased immediately, which looks very uneconomical, so people have devised a " copy-on-write (Copy-on-write)" technique that does not immediately replicate the contents of the parent process to the child process after the fork is finished. Instead, it is copied when it is actually used, so that if the next statement is exec, it will not be useless. In fact, "copy-on-write" or copy, the process of the MM structure, page tables are still copied ("Copy on Write" must also be supported by this information.) Otherwise, the kernel captures the CPU access exception, how to distinguish whether this is "copy-on-write" caused by, or the real ultra-vires visit it? ）。 and vfork to do things, all the memory of things are not copied, the parent-child process of memory is fully shared . But then there are problems, although the user program can design many ways to avoid the conflict between parent-child processes. But the key point is that the parent-child process is shared with the stack, which is not controlled by the user. When a process makes an operation about a function call or return, the call stack of another process (which is actually the same stack) is also affected. Such a program is not going to work. Therefore, Vfork has a restriction that, after a child process is generated, the parent process is suspended by the kernel in vfork until the child process has its own memory space (exec**) or exits (_exit). And, until then, the child process cannot be returned from the function that called vfork (at the same time, the variables on the stack cannot be modified and functions other than the _exit or exec series cannot be called, otherwise the parent process's data may be overwritten). Despite a lot of restrictions, vfork immediately after the exec efficiency will be much higher than fork.

/*EXEC.C*/
UNISTDH #include<.>
Mainvoid(void)
{
ENVPChar*[]={"path=/tmp","User=lingdxuyan","status=testing", NULL};
Argv_execvChar*[]={"Echo","excuted by Execv", NULL};
ARGV_EXECVPChar*[]={"Echo","executed by EXECVP", NULL};
Argv_execveChar*[]={"Env", NULL};
Fork0if(()==)
Execl0if(("/bin/echo","Echo","executed by Execl", NULL)<)
Perror ("ERR on Execl");
Fork0if(()==)
EXECLP0if(("Echo","Echo","executed by EXECLP", NULL)<)
Perror ("ERR on EXECLP");
Fork0if(()==)
Execle ENVP0if(("/usr/bin/env","Env", NULL,)<)
Perror ("ERR on Execle");
Fork0if(()==)
EXECV Argv_execv0if(("/bin/echo",)<)
Perror ("ERR on Execv");
Fork0if(()==)
EXECVP ARGV_EXECVP0if(("Echo",)<)
Perror ("ERR on EXECVP");
Fork0if(()==)
Execve Argv_execve envp0if(("/usr/bin/env",,)<)
Perror ("ERR on Execve");
}

Because the order in which each sub- process executes is uncontrollable, it is possible to have a confusing output-the results of each child process being printed mixed together rather than strictly in the order listed in the program. If you change the fork in the program to Vfork, the program executed by each exec executes sequentially.