I find it easier to understand in terms of the Unix syscall API. `2>&1` literally translates as `dup2(1, 2)`, and indeed that's exactly how it works. In the classic unix shells that's all that happens; in more modern shells there may be some additional internal bookkeeping to remember state. Understanding it as dup2 means it's easier to understand how successive redirections work, though you also have to know that redirection operators are executed left-to-right, and traditionally each operator was executed immediately as it was parsed, left-to-right. The pipe operator works similarly, though it's a combination of fork and dup'ing, with the command being forked off from the shell as a child before processing the remainder of the line.

Though, understanding it this way makes the direction of the angled bracket a little odd; at least for me it's more natural to understand dup2(2, 1) as 2<1, as in make fd 2 a duplicate of fd 1, but in terms of abstract I/O semantics that would be misleading.

It's a reminder of how archaic the systems we use are.

File descriptors are like handing pointers to the users of your software. At least allow us to use names instead of numbers.

And sh/bash's syntax is so weird because the programmer at the time thought it was convenient to do it like that. Nobody ever asked a user.

Man I miss stack overflow. It feels so much better to ask humans a question then the machine, but it feels impossible to put the lid back on the box.

Better: Understanding Linux's File Descriptors: A Deep Dive Into '2>&1' and Redirection https://news.ycombinator.com/item?id=41384919 https://news.ycombinator.com/item?id=39095755

A.I. has made the self-important neckbeards of Stack Overflow obsolete.

Not sure why this link and/or question is here, except to say LLMs like this incantation.

It redirects STDERR (2) to where STDOUT is piped already (&1). Good for dealing with random CLI tools if you're not a human.

I know the underlying call, but I always see the redirect symbols as indicating that "everything" on the big side of the operator fits into a small bit of what is on the small side of the operator. Like a funnel for data. I don't know the origin, but I'm believing my fiction is right regardless. It makes <(...) make intuitive sense.

The comment about "why not &2>&1" is probably the best one on the page, with the answer essentially being that it would complicate the parser too much / add an unnecessary byte to scripts.

Redirects are fun but there are way more than I actually routinely use. One thing I do is the file redirects.

    diff <(seq 1 20) <(seq 1 10)

I've almost never needed any of these, but there's all sorts of weird redirections you can do in GNU Bash: https://www.gnu.org/software/bash/manual/bash.html#Redirecti...

It means redirect file descriptor 2 to the same destination as file descriptor 1.

Which actually means that an undelrying dup2 operation happens in this direction:

   2 <- 1   // dup2(2, 1)

The notation follows I/O redirections: cmd > file actually means that a descriptor [n] is first created for the open file, and then that descriptor's decription is duplicated into [1]:

   n <- open("file", O_RDONLY)
   1 <- n

So if i happen to know the numbers of other file descriptors of the process (listed in /proc), i can redirect to other files opened in the current process? 2>&1234? Or is it restricted to 0/1/2 by the shell?

Would probably be hard to guess since the process may not have opened any file once it started.

> I am thinking that they are using & like it is used in c style programming languages. As a pointer address-of operator. [...] 2>&1 would represent 'direct file 2 to the address of file 1'.

I had never made the connection of the & symbol in this context. I think I never really understood the operation before, treating it just as a magic incantation but reading this just made it click for me.

back when stackoverflow was still good and useful, I asked about some stderr manipulation[0] and learnt a lot from the replies

[0] https://stackoverflow.com/questions/3618078/pipe-only-stderr...

I enjoyed the commenter asking “Why did they pick such arcane stuff as this?” - I don’t think I touch more arcane stuff than shell, so asking why shell used something that is arcane relative to itself is to me arcane squared.

If you need to know what 2>&1 means, then I would recommend shellcheck

It's very, very easy to get shell scripts wrong; for instance the location of the file redirect operator in a pipeline is easy to get wrong.

I saw this newer bash syntax for redirecting all output some years ago on irc

    foo &> file  
    foo |& program

It means someone did not bother to name their variables properly, reminding you to use a shell from this century.

I always wondered if there ever was a standard stream for stdlog which seems useful, and comes up in various places but usually just as an alias to stderr

A gotcha for me originally and perhaps others is that while using ordering like

   $ ./outerr  >blah 2>&1

   $ ./outerr  | 2>&1 cat >blah
   err

    (where outerr is the following...)
    echo out 
    echo err >&2

I understand how this works, but wouldn’t a more clear syntax be:

command &2>&1

Since the use of & signifies a file descriptor. I get what this ACTUALLY does is run command in the background and then run 2 sending its stout to stdout. That’s completely not obvious by the way.