3 ms·

> 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 initiate

> 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.

goku12 7mo 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.
- wahern 7mo ago
  > Honestly, I wish I could ask the person who designed it, why they made such decisions. https://web.archive.org/web/20250115051355/https://www.bell-labs.com/usr/dmr/www/hist.html https://web.archive.org/web/20250115051355/https://www.bell-... https://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf https://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf https://www.in-ulm.de/~mascheck/bourne/index.html#origins https://www.in-ulm.de/~mascheck/bourne/index.html#origins They also include citations to papers by Thompson, Bourne, and others.

goku12 7mo 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.

wahern 7mo ago
> Honestly, I wish I could ask the person who designed it, why they made such decisions. https://web.archive.org/web/20250115051355/https://www.bell-labs.com/usr/dmr/www/hist.html https://web.archive.org/web/20250115051355/https://www.bell-... https://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf https://www.cs.dartmouth.edu/~doug/sieve/sieve.pdf https://www.in-ulm.de/~mascheck/bourne/index.html#origins https://www.in-ulm.de/~mascheck/bourne/index.html#origins They also include citations to papers by Thompson, Bourne, and others.