What does 2> mean in bash?

>dry is equal to 1>. The number in front of >the is the descriptor that is being redirected.

Descriptor 1 is stdout(standard output). Descriptor 2 is stderr(error output). By default, both descriptors are associated with the terminal, but thanks to these operators we can redirect them to files independently. For example:

comando > fichero.txt

redirects standard output to that file, but leaves error output still visible on the screen.

comando 2> errores.txt

would redirect the error output to disk, but leave the standard output visible on the screen. It is also possible:

comando > salida.txt 2> errores.txt

to send to different files each of them.

Finally &>, it joins both descriptors and redirects them to the same file:

comando &> salida_y_errores.txt

TL;DR

It refers to redirecting the standard error stream.

extended explanation

In Unix and Linux we have a concept called a "standard stream" which is an interconnected stream of input and output data. There are three standard streams: input, output, and error. However, the latter has its peculiarity.

First of all, in the story it is said that this idea of ​​sending the flow of data from one program to another was the idea of ​​Douglas McIlroy, who insisted that Ken Thompson implement this idea. After insisting (they didn't think it was necessary to implement it), the way of looking at Unix was revolutionized.

On the other hand, this idea of ​​standard error arises because the programs worked in the input-output way; but this led to the semi-predicate problem , in which a subroutine that is designed to work just fine suddenly throws an error, and there is no way to identify this error from valid data.

There is the famous example of a division by 0. Clearly it will give us an error because that operation is not defined for real numbers. So how do we handle it? We can do this by returning a zero when the denominator is zero; but this is a bad idea, since also zero divided by any number is zero; then we have two sets of outputs (one from solutions, and one from inconsistencies) merged into the same output. If we want to assign any other number, we fall into the same thing; since assigning any real number would also be confused because the image of the function is in all the reals, making the solution indiscernible from what was craftily produced by an inconsistency.

For this reason, Denis Ritchie came up with a way to solve this problem and created a new data stream called "standard error" ( standard error , stderr ). In this way, the programs connected to the output would only receive the expected result, and the unexpected one would belong to this other flow but now be discernible.

On the other hand, file descriptors are natural numbers that function as interfaces between the user and a resource. These file descriptors are associated with the standard streams, it being agreed that 0 refers to the input (read) stream, 1 to the output (write), and 2 to the error (also for write).

Each of these file descriptors belongs to a kernel-managed file descriptor table, and is associated with an API that allows read, write, close, and so on.

Each file descriptor provides an abstraction layer over the resources. So when you want a program to read, 0 is associated with it; when you want me to write, the 1; when you want it to do something with the standard error, you use 2.

In Bash we have several ways to open a file "<" (read), ">" write, ">>" append. Each of these operations opens a file in some way (creat, open), returns a file descriptor, and thus allows the data to be manipulated. Something similar happens with anonymous pipes (the pipe symbol | ). Here Bash assumes that "<" is for reading, so it assumes a "0<"; or that ">" is to redirect the standard output "1>". So when you handle the number 2, you're making use of this error flow:

$ comando 2> archivo
$ comando > archivo 2>&1 # Aqui unimos el stderr con el stdout

And finally, Bash allows you to refer to both stderr and stdout at the same time with the &> token:

$ comando &> archivo

So both error and standard output will go to the file.

A graphic example is this:

Where a program that only has a sleepand a cat, we redirect its standard input, output, and error streams to each file with a respective suffix to the file descriptor.

To see its file descriptors we just use lsof.

But notice how there are three file descriptors but, at least there, two types of system calls: one for reading "r" (bound to 0), and one for writing "w" (bound to 1 and 2).

>redirects the standard output (STDOUT) of a process to a file

2>redirects the error output (STDERR) of a process to a file.