Comment by shevy-java

8 hours ago

> Those abstractions used to make perfect sense for those with prior knowledge but can also carry subtle bias which makes their use error prone for non initiated users.

I don't think 2>&1 ever made any sense.

I think shell language is simply awful.

1 comment

shevy-java

Reply
goku12  3 hours ago

> I don't think 2>&1 ever made any sense.

It's not that hard. Consider the following:

  $ command &2>&1

The shell thinks that you're trying to run the portion before the & (command) in the background and the portion after the & (2>&1) in the foreground. There is just one problem. The second part (2>&1) means that you're redirecting stderr/fd2 to stdout/fd1 for a command that is to follow (similar to how you set environment variables for a command invocation). However, you haven't specified the command that follows. The second part just freezes waiting for the command. Try it and see for yourself.

  $ command 2>1

Here the shell redirects the output of stderr/fd2 to a file named 1. It doesn't know that you're talking about a file descriptor instead of a filename. So you need to use &1 to indicate your intention. The same confusion doesn't happen for the left side (fd2) because that will always be a file descriptor. Hence the correct form is:

  $ command 2>&1

> I think shell language is simply awful.

Honestly, I wish I could ask the person who designed it, why they made such decisions.