Discuss the implementation principle of>/dev/null2> & 1 in shell commands

Discuss the implementation principle of & gt;/dev/null2 & gt; & amp; 1 in shell commands. first, standard input, standard output, and standard error: standard input is the location where the program can read its input. By default, the process reads stdin from the keyboard. Standard output is the location where the program writes its output. By default, the process will...
Explore the implementation principles of>/dev/null 2> & 1 in shell commands. first, standard input, standard output, and standard error: standard input is the location where the program can read its input. By default, the process reads stdin from the keyboard. Standard output is the location where the program writes its output. By default, the process writes stdout to the terminal screen. A standard error is the location where the program writes its error message. By default, the process writes stderr to the terminal screen.
Why are there three important concepts? We know that to run a program, you must have input and output. If an error occurs, you must be able to display your own errors. This requires reading data from somewhere and outputting data to somewhere. If an error occurs, you need to get the error somewhere. this is enough for data stream ). Therefore, each Unix program opens three streams at startup, one for input, one for output, and the other for printing diagnostic or error messages. Www.2cto.com has these three concepts. in other words, redirection: data stream redirection refers to the execution return value after an instruction (command) is executed. Generally, these return values are the result data displayed on the screen after execution, if I don't want him to flow to the screen by default. so I can transmit the result data to other places, such as files or devices (such as printers, but everything in Linux is a file, so the printer is also a file ). in this way, the data is directed to other places. you know. so everything is output to the screen. if there is too much data, it will be too messy. we can't stand it either. and the terminal of the screen is off. something can no longer be found. if I redirect to a file. in this way, the execution logs can be saved for a long time.> data stream redirection: output-oriented, will replace the content of the oriented file.> data stream redirection: output-oriented, does not replace the content of the oriented file. will accumulate data behind the ass. continue to look at the File descriptor: www.2cto.com Wikipedia, as mentioned above in the free encyclopedia, the File descriptor (File des Criptor is a term in computer science. it is an abstract concept used to express references to files. The file descriptor is a non-negative integer in form. In fact, it is an index value that points to the record table for opening files for each process maintained by the kernel. When the program opens an existing file or creates a new file, the kernel returns a file descriptor to the process. In program design, some underlying programming is usually centered around the file descriptor. However, the file descriptor concept is often only applicable to operating systems such as UNIX and Linux.

File descriptors have two advantages: file descriptor-based I/O operations are compatible with the POSIX standard. In UNIX and Linux system calls, a large number of system calls depend on file descriptors. It seems that this is a bit abstract. that is to say, if the program is not opened, there is no file descriptor when the file is alone on the disk. imagine. the first open file is 0, the second is 1, and so on. A Unix operating system usually imposes a limit on the number of files that can be opened by each process. What's more, unix usually has a system-level limit. Of course, it is true that 0, 1 and 2 are already occupied by some concepts. In addition, after the system is started, you do not know how many files are opened.

So. generally, when we open a file, the descriptor is estimated to be large. however, this file descriptor has some disadvantages. for example, the complete code will become poorly readable. you want. 0, 1, 2 .... 22231: What is it? Fortunately, POSIX defines STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO to replace 0, 1, and 2. The definitions of these three symbolic constants are located in the header file unistd. h. The valid range of the file descriptor is 0 to OPEN_MAX. Generally, each process can open up to 64 files (0-63 ). For FreeBSD 5.2.1, Mac OS X 10.3, and Solaris 9, the maximum number of files that a process can open depends on the size of the system memory, the size of the int, and the restrictions set by the system administrator. Linux 2.4.22 cannot exceed 1,048,576. Www.2cto.com combines the above basic concepts: it is not difficult to understand the following. standard input (stdin): file descriptor is 0, use <or <; (you do not have to write 0 <或0<<吧.其实这个也没错.不过太累人了)其实可以理解为这个箭头指向哪里数据就往哪里跑.这里是输入(stdin).命令就通过<来获取数据.等于数据是从左边往命令里面流. 标准输出 (stdout)：文件描述符为 1 ，使用> Or >>; (you don't have to write it as 1> or 1>. In fact, this is true, but it's too tired.) when outputting, if not <或者<<,因为命令总是在前面嘛.这里命令要输出数据.所以数据的来源是命令,数据就会随着箭头指向你给的方向. 标准错误输出(stderr)：文件描述符为 2 ，使用> Or 2 >>; for example: first, command> file 2> file means to send the standard output information and error output information generated by the command to file. command> file 2> file: both stdout and stderr are directly sent to file. the file will be opened twice, so that stdout and stderr will overwrite each other, in this way, two pipelines are used to seize the file at the same time. targeted twice. if you use the command> file 2> & 1, stdout is directly sent to file. stderr inherits the first redirection (FD1) to the MPs queue and is sent to file, file is opened only once, and only one pipeline FD1 is used. It includes stdout and stderr contents. it can also be understood in this way. I want to connect the file to the standard output using a pipe. then, output the standard error represented by 2 to the standard information represented by 1. all are directed to the file. in terms of IO efficiency, the efficiency of the previous command is better A command is less efficient, so when writing shell scripts, we use command> file 2> & 1 for many times. look at an instance (to enhance understanding, this instance references an online blog. q: What is the output of the following program? (Intel test 2011) www.2cto.com 1int main () {2 fprintf (stdout, "Hello"); 3 fprintf (stderr, "World! "); 4 return0; 5} and the output is World! Hello instead of: Hello World! Why? By default, stdout is a row buffer, and its output will be placed in a buffer. it will be output to the screen only when the line breaks. Stderr is unbuffered and will be output directly. for example, it is printf (stdout, "xxxx") and printf (stdout, "xxxx \ n"). The former will hold off, it is not output until a new line is encountered. Printf (stderr, "xxxxx") is output regardless of \ n. Finally: www.2cto.com to see what is/dev/null 1UFO @ UFO ~: Cd/dev2UFO @ UFO:/dev $ ls-l null3crw-rw-rw-1 root 1, 3 Feb 14 2012 null to see it? It's a character device file (c). What about this? You can call him "black hole", Blackhole? NO. it's not a black hole in astronomy. it is very equivalent to writing only files. all content written to it will be lost forever. however, you cannot read anything from it. however,/dev/null is very useful for both the command line and script. let's take a look at the stdio in the glibc Library. in the h header file: 1 # define stdin (& __ sF [0]) 2 # define stdout (& __ sF [1]) 3 # define stderr (& __ sF [2]) for example, www.2cto.com 1 fprintf (stderr, "UFO \ n"); // "UFO" will be output as a standard error in shell commands, and 0, 1 and 2 correspond to stdin in glibc respectively, stdout and stderr: 0 corresponds to stdin, that is, standard input 1 corresponds to stdout, that is, standard output 2 corresponds to stderr, that is, standard error output. So>/dev/null indicates that the program is printed The information of the stdout file whose handle is 1 is sent to the/dev/null empty file. the kernel implementation corresponding to the/dev/null node is to directly return the number of written bytes, therefore, the program thinks that it is successfully stored in/dev/null, but the>/dev/null operation cannot replace fprintf (stderr, "UFO \ n ") send the string printed on stderr to>/dev/null, so you must use the 2> & 1 Command to forward the data from shell to 2 stderr to 1 stdout, so the information displayed on terminal in stderr will also be transferred to/dev/null. let's look at another instance: 01luther @ gliethttp :~ $ Cat a. c02 # include 03int main (int argc, char * argv []) 04 {05 fprintf (stdout, "luther stdout \ n"); 06 fprintf (stderr, "luther stderr \ n "); 07 return 0; 08} 09luther @ gliethttp :~ $ Gcc a. c10luther @ gliethttp :~ $./A. out11luther stdout12 www.2cto.com luther stderr13luther @ gliethttp :~ $. /. Out>/dev/null14luther stderr // you can see that>/dev/null does not send stderr information to/dev/null to write a test. sh script 01luther @ gliethttp :~ $ Chmod + x test. sh02luther @ gliethttp :~ $ Cat test. sh03exec./a. out>/dev/null04luther @ gliethttp :~ $./Test. sh05luther stderr // you can see that the shell does not send stderr information to 06luther @ gliethttp: ~ under/dev/null :~ $ Cat test. sh07exec./a. out>/dev/null 2> & export Luther @ gliethttp :~ $./Test. sh09luther @ gliethttp :~ $ // No output, stderr information is converted to stdout information by the 2> & 1 command, and then sent to/dev/null to drown 10luther @ gliethttp :~ $ Cat test. sh11exec./a. out>/dev/null 1> & 212./test. sh13luther stdout14luther stderr15luther @ gliethttp :~ $ Of course, the tee operation also has the above problem. if the log printed to stderr cannot be captured by the tee operation, stderr can be redirected to stdout to solve this problem, www.2cto.com: 01luther @ gliethttp :~ $./A. out02luther stdout03luther stderr04luther @ gliethttp :~ $./A. out | tee luther.txt 05 luther stdout06luther stderr07luther @ gliethttp :~ $ Cat luther.txt 08 luther stdout09luther @ gliethttp :~ $./A. out 2> & 1 | tee luther.txt 10 luther stderr11luther stdout12luther @ gliethttp :~ $ Cat luther.txt 13 luther stderr14luther stdout15luther @ gliethttp :~ $./A. out 1> & 2 | tee luther.txt 16 luther stderr17luther stdout18luther @ gliethttp :~ $ Cat luther.txt 19luther @ gliethttp :~ $ // Nothing, because stdout is directed to stderr, so all log information cannot be captured by tee 20 for 1> & 2 because it will be parsed by shell as a command, so it can be put anywhere. 1> & 2 will affect all the log output of this group of commands, for example, 21luther @ gliethttp :~ $1> & 2./a. out | tee luther.txt 22 www.2cto.com luther stderr23luther stdout24luther @ gliethttp :~ $./A. out 1> 2 // only stderr25luther stderr26luther @ gliethttp :~ $. /. Out 2> 1 // only output stdout27luther stdout OK. I don't want to write it. very busy. in the above article, I just tried to integrate a lot of articles on the Internet that were scattered around the world due to large copies. so I made a big copy on the shoulders of giants. thank those giants. in fact, the concept mentioned above cannot be completely explained in this integrated article. more Related concepts include practices, reading documents, and adding your own brain to filter and think. I hope to discuss with you!