Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to understand the & symbols and file descriptors in Bash. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

As we explore all the miscellaneous symbols that appear in most chained Bash commands (&, |,;, >, list.txt

Pass the ls output to the list.txt file.

Now what we see is an abbreviation:

Ls 1 > list.txt

In this case, 1 is a file descriptor pointing to standard output (stdout).

In a similar manner, 2 points to standard error output (stderr):

Ls 2 > error.log

All error messages are piped to the error.log file.

Recall that 1 > is standard output (stdout) and 2 > is standard error output (stderr).

The shorthand of the third standard file descriptor, 0): >.

For example, things like stderr (2) are convenient when you know that your command will throw an error, but what Bash tells you is useless and you don't need to see it. To create a directory in the home/ directory, for example:

Mkdir newdir

If newdir/ already exists, mkdir will display an error. But why do you care? Well, in some cases you may care, but not always. At the end of the day, newdir will somehow ask you to fill in something. You can suppress the error message by pushing the error message into the void (i.e. `/ dev/null):

Mkdir newdir 2 > / dev/null

This is not just "Let's not see ugly and irrelevant error messages, because they are annoying," because in some cases, error messages can cause a series of errors elsewhere. For example, you want to find all the .service files under / etc. You can do this:

Find / etc-iname "* .service"

However, it turns out that on most systems, find displays errors with many lines because the average user does not have read access to some folders under / etc. It makes it difficult to read the correct output, and if find is part of a larger script, it may cause the next command on the line to be queued.

Instead, you can do this:

Find / etc-iname "* .service" 2 > / dev/null

And you only get the results you want.

Getting started with file descriptors

The separate file descriptors stdout and stderr also have some considerations. If you want to store the output in a file, do the following:

Find / etc-iname "* .service" 1 > services.txt

It works fine because 1 > means "send standard output and its own standard output (non-standard error) to somewhere".

But there is a problem: what should you do if you want to record the error message thrown by the command to a file and there is no error message in the result? The above command does not do this because it only writes the correct result of find, and:

Find / etc-iname "* .service" 2 > services.txt

Only error messages thrown by the command are written.

How do we get both? Try the following command:

Find / etc-iname "* .service" & > services.txt

…… Say hello to & again!

We keep saying that stdin (0), stdout (1), and stderr (2) are "file descriptors". A file descriptor is a special construct that is a channel to a file for reading or writing, or both. This comes from the old UNIX idea that everything is treated as a file. Want to write a device? Treat it as a file. Want to write sockets and send data over the network? Treat it as a file. Want to read and write files? Well, obviously, think of it as a document.

Therefore, when managing the output of the command and the wrong location, the target is treated as a file. So when you open them to read and write them, they all get file descriptors.

This is an interesting effect. For example, you can pass content from one file descriptor to another:

Find / etc-iname "* .service" 1 > services.txt 2 > & 1

This directs stderr to stdout, while stdout is piped to services.txt in a file.

It appears again: & signal that Bash 1 is the target file descriptor.

Another problem with standard file descriptors is that when you transfer from one pipe to another, the order in which you do this is a bit counterintuitive. For example, follow the above command. It looks like the wrong way. You can also read it like this: "direct the output to the file, and then direct the error to standard output." It looks like the error output will come later and will not be sent until the output to standard output (1) has been completed.

But that's not how file descriptors work. The file descriptor is not the placeholder of the file, but the input and / or output channel of the file. In this case, when you do 1 > services.txt, you mean "open a write pipe to services.txt and keep it open". 1 is the name of the pipe you want to use, which will remain open until the end of the line.

If you still think this is the wrong way, try this:

Find / etc-iname "* .service" 2 > & 11 > services.txt

And notice how it doesn't work; notice how the error is directed to the terminal, and only the non-error output (that is, stdout) is pushed to the services.txt.

This is because Bash processes each result of find from left to right. Think of it this way: when Bash reaches 2 > & 1, stdout (1) is still the channel to the terminal. If the result find gives Bash contains an error, it will be popped to 2, transferred to 1, and left on the terminal!

Then at the end of the command, Bash sees that you want to open stdout (1) as a channel to the services.txt file. If no error occurs, the result will enter the file through channel 1.

By contrast, in:

Find / etc-iname "* .service" 1 > services.txt 2 > & 1

1 points to services.txt from the beginning, so anything that pops up to 2 leads to 1, and 1 already points to its final location, services.txt, which is why it works.

In any case, as mentioned above, & > is an abbreviation for "standard output and standard error", that is, 2 > & 1.

It may be a little too much, but don't worry. Redirecting file descriptors is common on the Bash command line and in scripts.

This is the end of how to understand the & symbols and file descriptors in Bash. I hope the above content can be helpful to you and learn more. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.