System () function source code

The system () function is powerful, but many people do not know much about its principles. First look at the source code of the Linux system function:

# Include <sys/types. h>
# Include <sys/Wait. H>
# Include <errno. h>
# Include <unistd. h>

INT system (const char * character string)

{
Pid_t PID;
Int status;

If (else string = NULL ){

Return (1 );
}

If (pid = fork () <0 ){

Status =-1;
}

Else if (pid = 0 ){

Execl ("/bin/sh", "sh", "-c", character string, (char *) 0 );

-Exit (127); // The sub-process will not execute this statement if it is executed normally.

}

Else {

While (waitpid (PID, & status, 0) <0 ){

If (errno! = Einter ){

Status =-1;

Break;

}

}

}

Return status;

}

First, let's analyze the principle and then look at the above Code to understand it:
If the command received by system is null, the system returns directly. Otherwise, fork generates a sub-process, because fork returns both in two processes: parent process and child process. Check the returned PID here, fork returns 0 in the child process and PID of the child process in the parent process. The parent process uses waitpid to wait until the child process ends. The child process calls execl to start a program to replace itself, execl ("/bin/sh", "sh", "-c", character string, (char *) 0) is to call shell, the shell path is/bin/sh, the subsequent strings are all parameters, and then the sub-process becomes a shell process. The shell parameter
The parameter string is the parameter accepted by the system. In Windows, shell is a command. You must be familiar with what shell did after receiving the command.

If you do not understand the above, I will explain the fork principle: When process a calls fork, the system kernel creates a new process B, and copy the memory image of a to the process space of B. Because A and B are the same, how do they know whether they are parent or child processes, you can see the return value of fork. As mentioned above, fork returns 0 in the child process and the PID of the child process in the parent process.

In Windows, the situation is similar, that is, execl is changed to a smelly and long name, and the parameter name is also changed to make people dizzy. I found a prototype in msdn, let's take a look:

Hinstance ShellExecute (
Hwnd,
Lpctstr lpverb,
Lpctstr lpfile,
Lptstr lpparameters,
Lpctstr lpdirectory,
Int nshowcmd
);

For usage, see:

ShellExecute (null, "open", "C: \ A. Reg", null, null, sw_shownormal );

You may wonder that there is a parameter lpdirectory in ShellExecute that is used to pass the environment variable of the parent process, but execl does not exist in Linux, this is because execl is a compiler function (to some extent, hiding the specific system implementation). in Linux, it will then generate a Linux System Call execve. For the prototype, see:
Int execve (const char * file, const char ** argv, const char ** envp );

If you see this, you will understand why system () accepts the environment variables of the parent process. However, after you use system to change the environment variables, the main function returned by system remains unchanged. The cause can be seen from the implementation of system that it is implemented by generating a new process. From my analysis, we can see that there is no process communication between the parent process and the child process, child processes cannot change the environment variables of parent processes. I hope that we will not refute me with the call results of TC or the system in other compilers of the TC library. This is not a concept. DOS is too busy to play with Linux.