(no title)
skywal_l | 3 days ago
People who build a system or at least know how it works internally want to simplify their life by building abstractions.
As people come later to use the system with the embedded abstractions, they only know the abstractions but have no idea of the underlying implementations. 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.
shevy-java|3 days ago
I don't think 2>&1 ever made any sense.
I think shell language is simply awful.
goku12|3 days ago
It's not that hard. Consider the following:
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. 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: > I think shell language is simply awful.Honestly, I wish I could ask the person who designed it, why they made such decisions.
lukan|3 days ago
(But I won't claim that I am always able to strike the right balance here)
taneq|3 days ago
carlmr|3 days ago
The abstraction may be great, the problem is the lack of intuitive understanding you can get from super terse, symbol heavy syntax.