Asynchronously executes exec ("/alidata/server/php/bin/php/nas/wxdoctor/index.php App/common/wordspic/user_id/". $user _info[' user_id ']." /goods_id/". $goods _id. "." /open_id/". $user _info[' open_id '].">/dev/null 2>&1 &");
Discuss the implementation principle of >/dev/null 2>&1 in shell command first standard input, standard output, standard error: The standard input is where the program can read its input. By default, the process reads stdin from the keyboard. The standard output is where the program writes its output. By default, the process writes stdout to the terminal screen. The standard error is where the program writes its error message. By default, the process writes stderr to the terminal screen.
Why do you have these three very important concepts? We know that a program to run, need to have input, output, if the error, but also to show their own errors. It's about reading data from somewhere, outputting it somewhere, making mistakes and getting a place to go. That's enough to be a stream. So typically, each UNIX program opens three streams at startup, one for input, one for output, and one for printing diagnostics or error messages. With these three concepts. Besides, redirection: Data flow redirection (redirection) is the execution return value after execution of an instruction (command), typically the return value is the result data that appears on the screen after you execute it, if I don't want him to flow to the screen by default. Then I can transfer these results to other places, such as files or devices ( For example, the printer, but everything in Linux is a file, so the printer is also a file of such devices. So the data is going to be my guide to other places. You know. So everything is output to the screen, If there's too much data, it's too messy. And we can't stand it. And the screen is terminal. If I redirect to a file. This allows you to save the execution log for a long time. > Data Flow redirection: output-oriented, which replaces the directed file content .>> Data flow redirection: Output-oriented, does not replace the content of the directed file. The data is added to the back of the buttocks. Go ahead and look at the file descriptor:
Wikipedia, the free encyclopedia above, the file descriptor (filedescriptor) is a term in computer science, an abstraction that describes a reference to a file. The file descriptor is formally a non-negative integer. In fact, it is an index value that points to the record table in which the kernel opens a file for each process maintained by the process. When a program opens an existing file or creates a new file, the kernel returns a file descriptor to the process. In programming, some of the underlying programming often revolves around file descriptors. However, the concept of file descriptors is often applied only to operating systems such as UNIX and Linux.
There are two main advantages of file descriptors: I/O operations based on file descriptors are compatible with POSIX standards. In Unix, Linux system calls, a large number of system calls are dependent on the file descriptor. It seems that this thing is really a bit abstract. That is, if the program does not open, the file is lonely on the disk when there is no file descriptor. You can imagine. The first open file is 0, the second is 1, and so on. UNIX operating systems typically impose a limit on the number of files each process can open. What's more, UNIX usually has a system-level limitation. Of course, the situation is that 0,1,2 is generally already occupied by some concepts. Plus, the system started without knowing how many files were opened.
So. We usually open the file when the descriptor estimate has reached a very large number of data. But this file descriptor has drawbacks too. For example, the readability of the completed code becomes very poor. You want to, 0,1,2....22231, you know what it is? Fortunately, POSIX defines stdin_ Fileno, Stdout_fileno and Stderr_fileno to replace 0, 1, 2. The definition of these three symbolic constants is located in the header file unistd.h. The valid range of file descriptors is 0 to Open_max. In general, you can open up to 64 files (0-63) per process. For FreeBSD 5.2.1, Mac OS X10.3, and Solaris 9, the maximum number of files that can be opened per process depends on the size of the system memory, the size of the int, and the limits set by the system administrator. Linux 2.4.22 enforces a maximum limit of 1,048,576. The basic concept of the above: The following is not difficult to understand the . standard input (stdin): The file descriptor is 0, using < or <<; (you do not have to write 0< or 0<< it.) That's not true. But it's tiring. It can be understood that the arrow points to where the data goes. Here is the input (stdin). command to get data through <. Equals data is streamed from left to command . standard output (STDOUT): File descriptor 1, using > or >>; ( You don't have to be a 1> or a 1>>. But it's just too tiring. When the output is not used < or <<, because the command is always in front. Here's the command to output the data. So the source of the data is the command, The data will follow the arrows to the direction you gave . standard error output (STDERR): File descriptor 2, using 2> or 2>>; to illustrate: first command >file 2> File means that the standard output information generated by the command is sent to file with the wrong output information. Command >file 2>file Such a notation, stdout and stderr are sent directly to file, file will be opened two times, This way stdout and stderr will cover each other, so that it uses two channels to preempt file at the same time. Directed 2 times . If you use command >file 2>&1The stdout is sent directly to file, StdErr inherits the first redirect (FD1) to the pipeline, and then is sent to file, when file is opened only once, and only one pipe FD1 is used. It includes the contents of stdout and stderr. It is also possible to understand this. It is the standard output that the file is piped to. It then outputs the standard error of the 2 representation to the standard output of the 1 representative. It all leads to file. . from IO efficiency, The efficiency of the previous command is less efficient than the following command, so when writing a shell script, we use command> file 2>&1 as a way to write . to look at an example (deepen the relevant understanding, This instance refers to an online blog. Said to be Intel's written question: question: What is the output of the following program? (Intel written test) 1int main () {2 fprintf (stdout, "Hello");3 fprintf (stderr, "world!"); 4 Return0;5} and then discovers that the output is world! Hello instead of: Hello world! why is this? By default, stdout is buffered, and his output is placed in a buffer, which is output to the screen only when it is wrapped. And stderr is unbuffered, will be directly output, for example, printf (stdout, "xxxx") and printf (stdout, "xxxx\n"), the former will hold, until a new row will be output together. and printf (stderr, "xxxxx"), regardless of whether there is \ n, are output . last:
See what's called/dev/null 1[email protected]~:cd/dev2ufo@ufo:/dev$ls-l null3crw-rw-rw- 1 root root 1, 3 Feb 14& nbsp;2012 null See? is a character device file (c). And what about this thing? You can call him "black hole", blackhole? No. It's not a black hole in astronomy. It is very equivalent to a write-only file. All content written to it is lost forever. and trying to read from it is nothing. However,/dev/null is very useful for command lines and scripts. Take a look at the stdio.h header file in the GLIBC library: 1#define stdin (&__sf[0]) Define stdout (&__sf[1]) 3#define stderr (&__sf[2]) such as 1fprintf (stderr, "ufo\n");//Then the "UFO" as a standard error output in the shell command, 0,1 and 2 respectively corresponding to glibc stdin,stdout and stderr, above we have probably learned: 0 corresponds to stdin i.e. standard input 1 corresponds to stdout standard output 2 corresponds to stderr that is standard error output so >/dev/ Null means that the program through printf or fprintf printing to handle 1 stdout file information, sent to the/dev/null hole file,/dev/null node corresponding kernel implementation is directly return the number of bytes written, So the program thinks it is successfully stored in/dev/null, but >/dev/null this operation cannot send fprintf (stderr, "ufo\n") string to stderr, so you must use >/dev/null The &1 command indicates that the shell will send the data sent to the 2stderr into 1stdout, so that the information displayed in the STDERR will be forwarded to the/dev/null terminal . and an example: 01[ Email protected]:~$ cat A.c02#include03int Main (int argc, char *argv[]) 04{05 fprintf (stdout, "lutherstdout\n" );06 fprintf (stderr, "lutherstderr\n");07 return 0;08}09[email protected]:~$ gcc a.c10[ email protected]:~$./a.out11luther stdout luther stderr13[email protected]:~$./a.out >/dev/ Null14luther stderr//can see >/dev/null operation does not send stderr information to/dev/null write a test.sh script 01[email protected]:~$ chmod +x test.sh02[email protected]:~$ cat test.sh03exec./a.out >/dev/null04[email protected]:~$./ Test.sh05luther stderr //You can see that the shell will not send stderr information to/dev/null 06[email protected]:~$ cat Test.sh07exec./a.out >/dev/null 2>&108[email protected]:~$./test.sh09[email protected]:~$// Nothing is output, the stderr information is successfully changed into stdout information by the 2>&1 command, which in turn feeds into/dev/null flooded 10[email protected]:~$ cat test.sh11exec./a.out >/dev/null 1>&212./test.sh13luther Stdout14luther stderr15[email protected]:~$ of courseFor the tee operation also has the problem, if the print to stderr log will not be captured by the tee operation, so you can redirect stderr to stdout to resolve the problem, continue to see the example: 01[email protected]:~$. A.out02luther stdout03luther stderr04[email protected]:~$./a.out|tee luther.txt05luther Stdout06luther stderr07[email protected]:~$ cat Luther.txt08luther stdout09[email protected]:~$./a.out 2>&1|tee Luther.txt10luther stderr11luther stdout12[email protected]:~$ cat Luther.txt13luther stderr14luther stdout15[ email protected]:~$./a.out 1>&2|tee luther.txt16luther stderr17luther stdout18[email protected]:~ $ cat luther.txt19[email protected]:~$//Nothing, because stdout is directed to stderr, so all log information cannot be captured by tee 20 for 1>& 2 because as a command will be parsed by the shell, so where can be put, 1>&2 will affect all the log output of the group command, such as: 21[email protected]:~$ 1>&2./a.out|tee luther.txt22 www.2cto.com luther stderr23luther stdout24[email protected]:~$./a.out 1>2// Output only Stderr25luther stderr26[email protected]:~$./a.out 2>1//Output only Stdout27luther stdout
The implementation principle of >/dev/null 2>&1 in the
Go Shell command
